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