[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-dev] InterOp and Attribute Identifiers? - Re: [xacml-users]OASIS XACML InterOp Demo, RSA 2008, San Francisco, California, USA, April7-11 2008
Hi, Thank you to all who gave me better understanding of possible problems and solutions. And this is really good document: > From the xacml 2.0 interop document: > http://www.oasis-open.org/committees/download.php/24475/xacml-2.0-core-interop-draft-12-04.doc This helped us to make better and sustainable solution for our Grid authorisation interoperability project. I will send short information and link when we are ready to make it public. Thank you again for advice. Yuri Rich Levinson wrote: > Hi Yuri, > > Here are a couple of concrete examples highlighted below that the TC has > used for examples > in the core spec and for Interops. > > You will see there are no explicit guidelines, however for the ones we > "made up", i.e. invented > for examples, we included the terms such as : urn, oasis, names, tc, > xacml, 2.0, example, etc. > which can roughly be taken to mean that the identifier is a "urn" used > by the "oasis" "xacml" "tc" > for the "names" of attributes and obligations in the "example"s. > Similarly for the interop it was a "urn" used as an "example" for the > "xacml" "2.0" "interop". > > The terms an organization would typically use are terms related to the > "domain" of the > organization as Craig indicated. ex. "organization-name", > "organization-group" etc. > ex. prefix w related dns specifiers, i.e. a short sequence of unique > terms relevant to > the organization and activity they are being used for. > > Some related guidance is in the core spec here, which basically advises > making things > "easily indexable": > > 3392 In addition, functions that are strictly within an extension to > XACML MAY appear as a value for the > 3393 MatchId attribute, and those functions MAY use data-types that are > also extensions, so long as > 3394 the extension function returns a Boolean result and takes two > single base types as its inputs. The > 3395 function used as the value for the MatchId attribute SHOULD be > easily indexable. Use of non > 3396 indexable or complex functions may prevent efficient evaluation of > decision requests. > 3397 > > From the xacml 2.0 core spec: > > 1536 [a459] <Obligations> > 1537 [a460] <Obligation > *ObligationId="urn:oasis:names:tc:xacml:example:obligation:email"* > 1539 [a461] FulfillOn="Permit"> > 1540 [a462] <AttributeAssignment > *AttributeId="urn:oasis:names:tc:xacml:2.0:example:attribute:mailto"* > 1542 [a463] DataType="http://www.w3.org/2001/XMLSchema#string"> > 1543 [a464] <AttributeSelector RequestContextPath= > 1544 [a465] "//md:/record/md:patient/md:patientContact/md:email" > 1545 [a466] DataType="http://www.w3.org/2001/XMLSchema#string"/> ; > 1546 [a467] </AttributeAssignment> > 1547 > > From the xacml 2.0 interop document: > http://www.oasis-open.org/committees/download.php/24475/xacml-2.0-core-interop-draft-12-04.doc > > ref'd at: > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml#announcements > > > <Resource> > <Attribute > *AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" * > DataType="http://www.w3.org/2001/XMLSchema#string"> > <AttributeValue>CustomerAccount</AttributeValue> > </Attribute> > <Attribute > *AttributeId="urn:xacml:2.0:interop:example:resource:owner-id" * > DataType="http://www.w3.org/2001/XMLSchema#string"> > <AttributeValue>123456</AttributeValue> > </Attribute> > <Attribute > *AttributeId="urn:xacml:2.0:interop:example:resource:owner-name" * > DataType="http://www.w3.org/2001/XMLSchema#string"> > <AttributeValue>John Smith</AttributeValue> > </Attribute> > <Attribute > *AttributeId="urn:xacml:2.0:interop:example:resource:account-status"* > DataType="http://www.w3.org/2001/XMLSchema#string"> > <AttributeValue>Active</AttributeValue> > </Attribute> > </Resource> > > Those are just examples. There are no precise rules. Maybe a rough > guideline > would be 3-7 terms of 3-10 characters each, not to exceed say 40-50 chars > so that it is easily recognizable as a prefix and can easily fit on a > single line in an > xml structure. > > Thanks, > Rich Levinson > > Craig Forster wrote: >> Hi Yuri, >> >> I don't know what the best practices are, or what OASIS officially >> advises, >> but I'd avoid using the "urn:oasis:names:tc:xacml:2.0:" prefix for your >> custom identifiers. I think a good option would be too create a >> domain-specific namespace for your application to avoid confusion. >> >> Regards, >> Craig >> >> --------------------------------------------------------------- >> Craig Forster >> Software Engineer >> IBM Australia Development Labs >> Argus == https://w3.webahead.ibm.com/w3ki/display/commonauthz/Home >> Blog == http://blogs.tap.ibm.com/weblogs/craigforster/ >> --------------------------------------------------------------- >> >> >> >> From: Yuri Demchenko >> <demch@chello.nl> >> >> To: xacml-dev mailing list >> <xacml-dev@lists.oasis-open.org> >> >> Cc: Dee Schur <dee.schur@oasis-open.org>, >> ggebel@burtongroup.com >> >> Date: 05/03/2008 >> 19:52 >> >> Subject: [xacml-dev] InterOp and Attribute Identifiers? - Re: >> [xacml-users] OASIS XACML InterOp Demo, RSA 2008, San >> Francisco, California, USA, April 7-11 >> 2008 >> >> >> >> >> >> >> Hi Dee, >> Hi Gerry, >> >> Very interesting event! >> >> Actually this announcement triggered my request to the list about >> defining new attribute and obligation identifiers (see my message of >> March 4, 2007, "Subject: [xacml-dev] Any rules/regulations for defining >> new AttributeId...") >> >> Can you or somebody from potential interopers advice on the best >> practice for defining common attribute and obligation identifiers? >> >> In particular, using OASIS prefix "urn:oasis:names:tc:xacml:2.0:" vs own >> namespace vs URL style? >> >> Regards, >> >> Yuri Demchenko >> UvA, EGEE Project >> >> >> Dee Schur wrote: >> >>> OASIS XACML InterOp Demo, RSA Conference 2008, San Francisco, >>> California, >>> USA, April 7-11 2008, Booths 132-136 >>> >>> The eXtensible Access Control Markup Language (XACML) 2.0 OASIS Standard >>> >> has >> >>> emerged as a front runner in solving complex access control problems in >>> >> the >> >>> enterprise. Unlike the approach taken by proprietary access control >>> lists >>> (ACL), XACML is an industry accepted standard that provides a well >>> >> defined >> >>> structure to create rules and policy sets to make complex authorization >>> decisions. Enterprise practitioners have wished for greater >>> interoperability between products that support the XACML OASIS Standard. >>> >>> At the RSA Conference 2008 in San Francisco, April 7-11, nine >>> >> organizations >> >>> will come together to demonstrate interoperability of the eXtensible >>> >> Access >> >>> Control Markup Language (XACML) 2.0 OASIS Standard. Simulating a real >>> >> world >> >>> scenario provided by the U.S Department of Veterans Affairs; the demo >>> >> will >> >>> show how XACML ensures successful authorization decision requests and >>> the >>> exchange of authorization policies. Participants include: >>> >>> . Axiomatics >>> . BEA Systems >>> . IBM >>> . Oracle >>> . Red Hat >>> . Cisco >>> . Sun Microsystems >>> . U.S. Department of Veterans Affairs >>> >>> The Interoperability Demonstration will utilize the requirements >>> drawn in >>> the Healthcare industry based on work done at the U.S. Department of >>> Veterans Affairs, HL7, ASTM and ANSI. The requirements include >>> >> Role-Based >> >>> Access Control (RBAC), Privacy Protections, Structured and Functional >>> >> Roles, >> >>> Consent Codes, Emergency Overrides and Filtering of Sensitive Data. The >>> demonstration will highlight how XACML Obligations can provide >>> additional >>> capabilities in the policy decision making process, while taking the >>> >> health >> >>> care scenarios as example. Technical details of the demonstration, >>> >> including >> >>> Interoperability Configuration, Policy Decision Request and Policy >>> Interoperability, Roles and Privileges Modeling, Usage of XACML >>> >> Obligations >> >>> and SAML Identity Providers will be highlighted. >>> >>> The demonstration will occur in Booths 132-136 beginning April 7, 2008 >>> during Expo hours. There will be an opportunity for the RSA 2008 >>> >> attendees >> >>> to interact with the participating technologists. >>> >>> ***Please distribute to colleagues** >>> >>> For more information contact: jane.harnad@oasis-open.org or >>> dee.schur@oasis-open.org >>> >>> >>> >>> >>> -- >>> Gerry Gebel | VP & Service Director | Identity and Privacy Strategies | >>> <identityblog.burtongroup.com> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: xacml-users-unsubscribe@lists.oasis-open.org >>> For additional commands, e-mail: xacml-users-help@lists.oasis-open.org >>> >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: xacml-dev-unsubscribe@lists.oasis-open.org >> For additional commands, e-mail: xacml-dev-help@lists.oasis-open.org >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: xacml-dev-unsubscribe@lists.oasis-open.org >> For additional commands, e-mail: xacml-dev-help@lists.oasis-open.org >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]