[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 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]