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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: RE: [security-services] On allowing multiple value types for an attribute


Ah, I see it. But as Scott points out it is NOT required that you include a name identifier. For example, by using subject confirmation you can express semantics such as "the specified attribute values apply to the party presenting this assertion" (bearer) or "the specified attribute values apply to the party who can prove knowledge of the private key associated with the indicated public key" (HoK).

The silence in the profile is deliberate. XACML considers an entity to have one or more attributes which may or may not have a value unique to that entity. XACML policies can make decisions about entities which are not uniquely identified in any way. As much as possible we tried to avoid defining any attributes with special properties. (There are some exceptions.) We fought in the SS TC to continue to make the Subject optional in SAML 2.0 Assertions, feeling that it would be confusing to have a SAML Subject appear in an XACML Policy or Decision Request.

The XACML view is that there are environments where every Subject has a single unique identifier and other environments where Subjects are known to different Authorities by different identifiers. The latter is common in multi-IDP configurations.

The decision on how to define XSPA depends on the properties of the environment it will be used in. If Subjects always have a single unique identifier that all parties refer to them by, then by all means specify that this should appear as the name id in the SAML Subject and as the Subject-id in XACML requests and policies. If this is not the case, then you need to define a more flexible scheme. I don't personally think it is a good idea to have a SAML attribute which is called Subject-Id, but perhaps there are cases where this would make sense.

Hal

> -----Original Message-----
> From: Mohammad Jafari [mailto:mjafari@edmondsci.com]
> Sent: Wednesday, November 26, 2014 1:20 PM
> To: Cantor, Scott; Hal Lockhart; security-services@lists.oasis-open.org
> Subject: RE: [security-services] On allowing multiple value types for
> an attribute
> 
> Thanks Hal. I was referring to Section 2.7.3. line 1168: which requires
> Assertions containing <AttributeStatement> elements to contain a
> <Subject> element as well.
> 
> I think regardless of the optionality of the ID my questions about
> interoperability with XACML still remain:
> - Should the XACML subject-id be encoded as the ID under saml:Subject
> or as a SAML Attribute?
> - If saml:Subject includes an ID, should it be mapped into an XACML
> attribute?
> - If there is a subject-id in the SAML Attributes and there is also an
> ID under saml:Subject, should they match?
> 
> The XACML Attribute profile of SAML is currently silent about the above
> questions but we need to make decisions about these in XSPA.
> 
> Regards,
> Mohammad
> 
> 
> > -----Original Message-----
> > From: Cantor, Scott [mailto:cantor.2@osu.edu]
> > Sent: Wednesday, November 26, 2014 10:50 AM
> > To: Hal Lockhart; Mohammad Jafari;
> > security-services@lists.oasis-open.org
> > Subject: Re: [security-services] On allowing multiple value types for
> > an attribute
> >
> > On 11/26/14, 5:38 PM, "Hal Lockhart" <hal.lockhart@oracle.com> wrote:
> >
> > >I think he is referring to section 3.3.4 which says the response to
> > >any of the Query requests must contain a subject which matches the
> > >subject in the query. I don't see any practical way to do an
> > >attribute query without specifying an identifier element. Otherwise
> > >whose attributes should be returned?
> >
> > You could pass a SC element with a key in it, to use one example, or
> > it could be front-channel with a bearer SC in it.
> >
> > But in any case, the rule for a Response to a query isn't necessarily
> > something that has to apply to any assertion created with an
> attribute statement in it.
> > Though it seems that we did in fact required Subject (but not an ID)
> for that.
> >
> > -- Scott
> 


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