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] RE: [security-services] Moving subjects up to assertions


I have been chiming in loudly on this topic in the SAML
discussions, largely through Eve Maler, who stops in to see how
various proposals might impact XACML.

I think they have accepted the idea that subject-less assertions
are meaningful.  The strongest use case was our proposed
PolicyStatement Assertion, where there is an Issuer asserting
that the contents represent a policy issued by that Issuer, but
the Policy is not associated with any particular Subject.

Feel free to chime in, but be sure you read the complete thread
first - a lot has changed in the past week.

Anne

On 16 March, Polar Humenn writes: [xacml] RE: [security-services] Moving subjects up to assertions
 > From: Polar Humenn <polar@syr.edu>
 > To: XACML <xacml@lists.oasis-open.org>
 > Subject: [xacml] RE: [security-services] Moving subjects up to assertions
 > Date: Tue, 16 Mar 2004 09:00:16 -0500 (EST)
 > 
 > 
 > Hi,
 > 
 > I found this thread on the SAML list. As some references were made to
 > XACML, I would just like to chime, but in trying to write a response, I am
 > a bit concerned about how this plays out, in the Real-to-XACML world.
 > 
 > On Tue, 9 Mar 2004, RL 'Bob' Morgan wrote:
 > 
 > > On Tue, 9 Mar 2004, Reid, Irving wrote:
 > >
 > > > > "An assertion containing such a statement MUST contain a
 > > > > <Subject> element
 > > > > as defined by sec. XX. If a <Subject> is not provided, then any such
 > > > > statements are invalid and MUST be ignored.
 > > >
 > > > I'm not sure we need to be quite this strong. Based on previous
 > > > discussions, I suspect XACML would like to have AttributeStatement
 > > > elements without subjects.
 > >
 > > Really?  To me this would be like having an LDAP entry without a DN.
 > > Attributes have to be attributes of something, and that something is the
 > > Subject.  The Subject of an attribute statement doesn't have to be a
 > > Subject that could also be a Subject of an authentication statement.  That
 > > is, if I want to make a statement with attributes about that doorknob over
 > > there, I can make a Subject expression identifying the doorknob.  Is there
 > > really a use case for Subject-less attribute statements?
 > 
 > First I thought:
 > 
 >     I would doubt that we would like to see an AttributeStatement without
 >     a subject.  I personally see no point to that.
 > 
 >     In XACML, Subjects look exactly like Resources. Each is simply a
 >     collection of Attributes. The "role" of the collection of attributes
 >     plays is one of a Subject, a Resource, an Action, or the Environment,
 >     which basically models the Lampson Access matrix, of "subjects",
 >     objects", and "rights". Objects may be subjects.
 > 
 >     A AttributeAssertion should contain a "subject" as that is the role it
 >     plays in that statement, i.e. the "subject" to which the assertion
 >     attributes values.
 > 
 >     In XACML when we say that there may not be any subject, that basically
 >     means in a Policy there may not be any subject predicates. That is to
 >     say, the Policy may not care about the subject, in which case, it
 >     basically means "all" subjects. Note, the XACML 1.1 Access Decision
 >     Request Context requires at least one Subject, one Resource, one
 >     Action, and an optional Environment set of attributes.
 > 
 > 
 > Then I got to thinking about what I just said. An XACML entity whether it
 > be a subject, resource, action, or environment, is merely a set of
 > attributes that play a particular role in the access decision request.
 > Therefore a "resource" can easily become a "subject" of an access decision
 > request, (something like a intermediary).
 > 
 > Somehow, not specified in XACML, these attributes are tied together to
 > become a XACML Subject, Resource, Action, or an Environment.
 > 
 > If an Attribute Assertion ties attributes to a particular value, i.e. it's
 > subject, should that subject be just another attribute? say an "id"
 > attribute or a correlation attribute of some sort?
 > 
 > I was pretty dead against "subject-less" AttributeAssertions, but now I'm
 > not so sure.  A SAML subject is a very complex entity, whereas the
 > attribute is simple.
 > 
 > So, questions?
 > 
 > 1. Should attribute assertions merely group assertions together?
 > 
 > 2. Should they group attributes together and label certain attributes as
 >    correlation attributes?
 > 
 > 3. Should they associate attributes with a subject that is made up of
 >    other attributes? (kind of like 2, but may require that all
 >    subject attributes match before the assertion is valid).
 > 
 > or
 > 
 > 4. Should they associate attributes with a SAML complex subject, which
 >    seems to have all sorts of stuff, and write profiles for mappings to
 >    collections of attributes.
 > 
 > This is just some food for thought, right now. Just some my ramblings, I'm
 > writing down for notes, and sharing.
 > 
 > Cheers,
 > -Polar
 > 
 > 
 > 
 > 
 > 
 > 
 > > > One could also build a sort of "hard anonymity" by profiling
 > > > AuthenticationStatements that have no Subject (perhaps Shib could use
 > > > this, rather than short-lived pseudonyms).
 > >
 > > Once again, this seems like reaching for a use case, when we do perfectly
 > > well with Subject-based mechanisms today.
 > >
 > > I think having Subjects be required for these statements is much more in
 > > line with the simplicity we're both in favor of.
 > >
 > >  - RL "Bob"
 > >
 > >
 > > 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/security-services/members/leave_workgroup.php.
 > >
 > 
 > 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_workgroup.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]