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

Subject: Representing anonymous Subjects

Dear SAML'ers,

Recent discussions of the http binding have brought up
two flows that result in assertions about (potentially) anonymous
subjects.   These flows either involve an artifact (or "handle" in
Shibboleth) that is used to retrieve an assertion about the
browser user, or involve the assertion being "redirected" (so to speak)
through the user's browser (via interesting uses of javascript
and "post").
    Various discussions have flowed about impersonation
countermeasures and other aspects of these http-based flows.
I won't repeat them here.  Instead, I'd like to raise up the
question of the "Subject" element in the assertion.

In both flows (artifact or "bearer" assertion), it is possible  for
the assertion to have an anonymous (or pseudonymous) subject. (Note
that the assertion could be either an authN or attribute assertion.)
    Currently, the Subject element in the SAML schema (version 14)
doesn't seem to have a graceful way of dealing with the sorts of
anonymous subjects that arise from the http binding.
(I'll continue to say "anonymous subjects" to refer to both anonymity and
pseudonymity, and to mean the http binding case.)   Here's what it does
allow for  (to the extent that I understand the schema correctly).
I'll follow with a brief discussion on why none of the options seem
to have a good fit for the anonymous subject case.

The Subject element allows for 3 different types of identifiers. It
allows for
       --  a string "name" qualified by a security domain
       --  an "authenticator" field (mostly related to a subject
            authenticating with a key)
       --  a reference to another assertion or inclusion ofthat assertion

Why these don't really fit:
    - The string name could be used to convey the contents of the handle
or the "assertion id" part of the artifact, but neither of these is in
any way a subject 'name'.   I suppose that the RP could use the fake
name as a real name in its continued processing, but that is
conceptually incorrect, and it feels like looking for trouble to me.
(One concrete difficulty is how an RP could meaningfully have the notion
of "anonymous" in an authZ policy if it can't tell the difference
between a fake name referring to an anonymous user and a real user name.)
    - The authenticator field strikes me as being mostly related to
subjects with keys, but Phill (in a phone call with me) suggested
that it could be  used for the anonymous browser user case. I feel
reluctant about this because the association between an anonymous
browser user and an assertion is just that -- an association.  To refer
to it as an authentication just seems like a distortion of
both the term authentication and what is really going on from a
processing standpoint. (That is, the RP validates the association of
user and assertion rather than validating the identity of the user. )
     - The reference to an assertion or inclusion of one doesn't seem
to apply, because anonymous assertions in the http binding are (often)
the initial ones.  There is not necessarily any other assertion to refer
to (and there would still be the question of representing anonymity
in that assertion!).

Summary:  I don't think we currently have a good way of representing
either "bearer" assertions or anonymous assertions gotten via an artifact.
   A possible solution is the extension of the Subject field to
include an "anonymous" type.  But I'm no
XML expert. I'm hoping that if others agree that there is a need,
we can work out the XML specifics.


PS My apologies if I've misunderstood the meaning of the fields in
the current schema.  I welcome enlightenment.

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

Powered by eList eXpress LLC