OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xacml] Minutes of 20 May 2004 XACML Focus Group


If you want to name your resources in a way other than the std
URI syntax, all you have to do is write a simple Profile
describing how your resources are named.  This could be an XACML
TC Profile or it could be a Profile used only by BEA for BEA
resources.

The important thing is for any given resource type to be
identified in only one way.  Otherwise, policies might be written
against the resource assuming one naming scheme, but the Request
might come in using another naming scheme, and then the policy
will not apply (when it should).

Anne

On 20 May, Daniel Engovatov writes: RE: [xacml] Minutes of 20 May 2004 XACML Focus Group
 > From: Daniel Engovatov <dengovatov@bea.com>
 > To: Anne.Anderson@Sun.COM
 > Subject: RE: [xacml] Minutes of 20 May 2004 XACML Focus Group
 > Date: Thu, 20 May 2004 13:25:46 -0700
 > 
 > ..Or did I misunderstood something? :)
 > Sorry.
 > 
 > Just my use case does not fit well into any standardized hierarchical
 > name
 > Syntax (our naming authority in WLES giving our customers headaches - to
 > support old Crosslogix resource naming). 
 > 
 > I actually hooked up Sun's code as a test and it worked nicely with
 > "ancestors" approach.
 > 
 > Daniel.
 > 
 > -----Original Message-----
 > From: Anne Anderson [mailto:Anne.Anderson@Sun.COM] 
 > Sent: Thursday, May 20, 2004 12:56 PM
 > To: XACML TC
 > Subject: [xacml] Minutes of 20 May 2004 XACML Focus Group
 > 
 > Minutes from the 20 May 2004 XACML Focus Group
 > 
 > Present
 > 
 > Simon Godik
 > Michiharu Kudo
 > Anne Anderson
 > Ed Coyne
 > Frank Siebenlist
 > 
 > Very productive meeting!!!
 > 
 > Agenda:
 > 1. New RBAC Profile
 > 2. XACML Profile of SAML V2.0 Attributes
 > 3. Hierarchical Resources proposal
 > 
 > Minutes:
 > 
 > 1. New RBAC Profile
 >    http://lists.oasis-open.org/archives/xacml/200405/msg00070.html
 >      or
 >  
 > http://www.oasis-open.org/apps/org/workgroup/xacml/download.php/6806/wd-
 > xacml-rbac-profile-02.1.pdf
 > 
 >    Since comments are still coming in from xacml-comment, so we
 >    decided not to discuss this yet.
 > 
 > 2. XACML Profile of SAML V2.0 Attributes
 >    http://lists.oasis-open.org/archives/xacml/200405/msg00068.html
 > 
 >    Discusion of lines 94-96, which now say:
 >    
 >      "The value of the SAML Attribute's Name attribute SHALL be a
 >       URI reference that conforms to this format and that is
 >       sufficient to distinguish instances of this Attribute from
 >       instances of other SAML or XACML Attributes that have
 >       different semantics."
 > 
 >    Simon: why the term "URI reference" rather than just "URI"?
 > 
 > [ACTION ITEM] Anne to ask Eve why she used "URI reference".
 > 
 > [DONE]: Eve says "URI reference includes both URIs and URIs that
 > have a "#<internal name>" appended.  This term is defined in the
 > SAML glossary.
 > 
 >    Michiharu: In "conforms to this format", what is "this"?
 > 
 >    Anne: It is the format associated with the identifier
 >    "urn:oasis:names:tc:SAML:2.0:attname-format:uri".  That is, a
 >    URI.
 > 
 >    Michiharu: Why do we need a new "DataType" attribute as well as
 >    the "NameFormat" attribute?
 > 
 >    Anne: The "DataType" attribute is the data type of the
 >    <AttributeValue>.  The "NameFormat" attribute is the data type
 >    of the "Name".
 > 
 >    Simon: consider changing lines 94-96 to:
 > 
 >      "The value of the SAML Attribute's Name attribute SHALL be a
 >       URI that is sufficient to distinguish instances of this
 >       Attribute from instances of other SAML or XACML Attributes
 >       that have different semantics."
 > 
 > [ACTION ITEM] Anne to produce new draft with Simon's suggested
 > change, unless Eve's response indicates otherwise.
 > 
 >    Simon: should the Profile include something like "these
 >    attributes may be conveyed either in-band or out-of-band", in
 >    order to include SAML's Attribute meta-data proposal?
 > 
 >    Anne: looked at SAML's Attribute meta-data proposal, and it
 >    does not specify the XML attributes of an Attribute, but
 >    rather things like the location of the Attribute Authority
 >    that is responsible for issuing the Attribute.  Also, this
 >    Profile is carefully worded to say that this meta-data
 >    (i.e. DataType, Name, NameFormat) must be provided for each
 >    SAML Attribute, but does not specify how it is provided.
 > 
 >    Michiharu: should the Profile include how to map the SAML
 >    Attribute to an XACML Attribute?
 > 
 >    Anne: That is specified in a different Profile: XACML Profile
 >    for SAML:
 >  
 > http://www.oasis-open.org/committees/download.php/5854/wd-xacml-saml-pro
 > file-02.pdf
 > 
 >    The "XACML Profile of SAML V2.0 Attributes" is to be advanced
 >    within the SSTC.  Its audience is producers of SAML Attribute
 >    Assertions who want their Attribute Assertions to be
 >    consumable by XACML.
 > 
 >    The "XACML Profile for SAML" is to be advanced within the
 >    XACML TC.  Its audience is producers of components of XACML
 >    systems (PDP Context Handlers, PEPs, Policy Issuers) that want
 >    to use SAML Queries, Responses, and Assertions.  This Profile
 >    specifies how to map SAML Attributes (produced according to
 >    the "XACML Profile of SAML V2.0 Attributes" to XACML
 >    Attributes.  It also tells how how to issue XACML Policy
 >    queries and responses and XACML Authorization Decision queries
 >    and responses using SAML wrappers to provider issuer, validity
 >    period, and digital signatures.
 > 
 > [ACTION ITEM]: Anne to update the "XACML Profile for SAML" to be
 > compatible with most "XACML Profile of SAML V2.0 Attributes" and
 > with SAML 2.0 syntax.
 > 
 > 3. Hierarchical Resources proposal
 >    http://lists.oasis-open.org/archives/xacml/200405/msg00064.html
 > 
 >    There was general agreement that specifying a standard URI
 >    syntax for identifiers of hierarchical resource components is
 >    both do-able and useful.  These names should conform to IETF
 >    RFC2396: "Uniform Resource Identifiers (URI): Generic Syntax":
 > 
 >       <scheme> ":" <authority> "/" <pathname>
 > 
 >    where <pathname> is:
 > 
 >       <hierarchical component> [ "/" <hierarchical component> ]*
 > 
 >    The first <hierarchical component> should be the root of the
 >    hierarchy at the <authority>.  The syntax of each
 >    <hierarchical component> should be the representation of the
 >    component on the <authority> that hosts the resource.
 > 
 >    Since a single hierarchical resource may have multiple valid
 >    values for <pathname> (such as a UFS file whose path contains
 >    hard links), there must be a way to supply all valid
 >    <pathname> values so that policies that refer to a particular
 >    element in the hierarchy using one pathname will always be
 >    able to match.  Tentative conclusion is that multiple
 >    :resource-id AttributeValues should be supported for this
 >    (within a single <Resource>).  All such AttributeValues must
 >    refer to the same element in the <Resource>.
 > 
 >    Tim's URL match function proposal
 >    (http://lists.oasis-open.org/archives/xacml/200405/msg00075.html
 >    and following) can be used with the standard URI
 >    representation of hierarchical resource elements to do matches
 >    that take the hierarchical order of the elements into account.
 > 
 >    There was general agreement that Tim's URL match function
 >    should be extended to cover all URIs, and not just URLs.
 >    Since RFC2396 specifies that "/" is reserved as a separator
 >    between hierarchical components of the identifier, this means
 >    that matches can always be by component, regardless of the
 >    actual component syntax for various URI schemes.
 > 
 > [ACTION ITEM] Anne to produce new draft of the Hierarchical
 > Resources proposal that includes:
 > a. Standard URI syntax for hierarchical resources that are not
 >    XML documents.
 > b. New, expanded version of Tim's URL match function to include
 >    URIs in general.
 > 
 > -- 
 > Anne H. Anderson             Email: Anne.Anderson@Sun.COM
 > Sun Microsystems Laboratories
 > 1 Network Drive,UBUR02-311     Tel: 781/442-0928
 > Burlington, MA 01803-0902 USA  Fax: 781/442-1692
 > 
 > 
 > To unsubscribe from this mailing list (and be removed from the roster of
 > the OASIS TC), go to
 > http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgro
 > up.php.
 > 

-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]