RE: [security-services] Moving subjects up to assertions

[Polar Humenn <polar@syr.edu>]

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.
>