Artifacts : a slightly different (Shibboleth) perspective

[Marlena Erdos <marlena@us.ibm.com>]

Dear SAMLers,

  I've been reading the bindings work on
"artifacts" with interest.

  Shibboleth also has an artifact -- but
its semantics are slightly different.
And while Shibboleth covers a much narrower space
than SAML needs to, I think the
Shibboleth model may have some use
in furthering the bindings works.

  Here is a discussion of Shibb and the
Shibb artifact -- what it means and
how it is used. Along the way
I'll point out some differences from
the current bindings model.
  A much fuller discussion of Shibboleth's use
of artifacts can be found in the Shibboleth architecture
document (draft!).  The URL for that doc is:

http://middleware.internet2.edu/shibboleth/docs/draft-erdos-shibboleth-architecture-01.pdf


  Firstly, Shibboleth only has a "web browser profile" -- and no
other.  Our model is of a user accessing
a web resource over http(s).  The user logs into
their "home organization". The home organization
hosts an attribute authority which issues
attribute assertions in response to attribute
queries.   Shibboleth doesn't include
an authentication authority or authentication
assertions -- more about this
shortly.
  Since Shibboleth has a large emphasis on
user privacy, we had a conundrum: How can
a relying party (RP) "securely" associate an attribute assertion with
a user who is not identified to the RP?
  Our solution was for the home organization
to send an "attribute query handle" in a secured package
to the RP via a redirect through the user's browser.
(We have two "paths" to get to this redirect. I don't
want to make this note even longer, so please see the Shibb Arch
doc for details.)
  The RP then uses the attribute query handle (which
I'll just call a "handle" henceforth) to
make request for an attribute assertion at the home
organization's AA.   That is, the handle serves
as the "subject" of the request.
  Of particular note, is that the handle
can *not* be said to refer to an existing assertion.
  Since Shibboleth allows a user to choose
what attributes get released to each RP (including
"name"), the AA will create different attribute assertions
about a given user depending on the RP that
is making the request.
  In Shibboleth, the handle refers to the user
(albeit in an opaque way).

  The "secure package" for the handle,
is akin to the SAML "artifact".  We however
have a specific format rather than an
artifact framework.  Also, the contents
of our artifact are specifically aimed
at foiling impersonation rather than
eliminating replay per se.
  I'll send along an example of the
handle package in a separate note.  I'll
also include an explanation of the
impersonation attacks we try to defeat.


  To wrap up this note ...

  About authentication assertions: we
don't have them in Shibboleth.  The
RP by virtue of receiving a valid
handle package can infer that the user authenticated
to their home organization.  But that is it.
It is possible for "login method" to be included
as an attribute in the attribute assertion,
though thus far we've been
thinking about longer-lived attributes.

  About the "artifact": Thus far the
documentation of the artifact says
that the "assertion id" is used to
get an authentication assertion. Is there
any reason that the "id" couldn't
be used to retrieve an attribute assertion?

  About anonymity: We achieve anonymity
by using the opaque handle as the subject
for the attribute query.  SAML doesn't
yet allow this (though Phill seemed amenable
when I talked with him late last week).
The returned assertion may or may not
contain the user's identity. It depends
on what the user has allowed the attribute
authority to release.


Comments? Questions?  You can
send them to me but I'll unfortunately
be away from July 19 until Aug 5.
(You might wish to
refer Shibboleth-specific
questions to Bob Morgan as he too is a
Shibb designer.)


Regards.
Marlena