Shibboleth Developers

["Tom Scavo" <>]

Hi Weizhong,

On 10/31/07, wz qiang 
<>
 wrote:
>
> Could you explain a little more about the Grid Use Case?

Yes, of course.  See below.

> On 10/31/07, Tom Scavo 
> <>
>  wrote:
> > This use case distills the common requirements of various grid
> > projects I've worked on, and so it might be called the "Grid Use
> > Case":
> >
> > 1. The IdP asserts an SSO assertion with the following characteristics:
> > * The assertion is unencrypted
> > * There is a digital signature on the <Assertion> element
> > * The <AuthnContext> element distinguishes between two levels of assurance
> > * The IdP asserts a persistent, non-reassignable identifier (encrypted)
> > * The assertion may contain non-identity attributes such as ePSA
> (unencrypted)
>
> So the IdP will do two things: authenticate the user by using the user's
> identity certificate, and acquire attribute for the user?

The IdP authenticates the user, yes, but the method of authentication
is out of scope.  However, we require the IdP to assert a level of
assurance (LoA) associated with the act of authentication.  There's a
lot of discussion going on right now regarding LoA, but from our point
of view there are just two levels: low and high.  LoA is determined
solely by the vetting process the user was subjected to to obtain the
credential used to authenticate to the IdP.

Let me give an example.  At the University, prospective students are
given an account via some online process.  There is no identity
proofing that occurs in this case, so the issued credential
(username/password) is low LoA.  When that student matriculates at the
University, s/he appears in person at the Help Desk and provides a
Driver's License before receiving a University ID.  At that time, the
credential becomes high LoA.  Same credential, different point in
time, different LoA.

As far as attributes are concerned, we require none from the IdP.  If
the IdP were to assert eduPersonScopedAffiliation, that would be
helpful, but it's not required.  What IS required is a persistent,
non-reassignable identifier (such as eduPersonTargetedID).  The Grid
SP uses this identifier to do account linking.

> > 2. The SP decrypts the identifier and maps it to a persistent, local
> > identifier (account linking).
>
> What is the scenario if local identifier mapping/linking?

So now the user presents a SAML identity token to the SP.  The
identity token carries the identifier and the LoA associated with the
act of authentication.  Let's suppose for simplicity there are no
attributes embedded in the token.

If this is the first time the SP has seen this particular identifier,
a local account is created, that is, a local identity.  Also, the user
is asked to provide an e-mail address, where after a confirmation
e-mail is sent to the user.  In this way, the SP ends up with a
mapping from the user's campus identity to this new local identity.
Moreover, a working e-mail address is associated with this mapping.
Now we're off and running.

> some gridmap-like thing?

Actually, yes.  Gridmap is a type of account linking.  You can think
of account linking at the SP as a kind of gridmap if you like.  The
linking we have in mind is much richer, however.

> For the SP or the application, do they still authenticate the user once more
> by using the user's identity certificate, or they just rely on the assertion
> from the IdP (identity asserted by IdP)?

That's an important question.  No, the SP does not authenticate the
user.  That's the whole point in fact.  Only the IdP authenticates the
user.  The local account at the SP is needed because we're going to
assign local attributes to the user (more on that later).

By the way, the user doesn't possess an X.509 credential (unless that
is in fact the way the IdP prefers to authenticate its users).  The SP
will request grid resources on behalf of the user.  All the X.509
stuff is hidden behind the portal.

> what is the non-assignable identifier?

The identifier asserted by the IdP must have two properties: it must
be persistent and non-reassignable.  It is persistent so that the SP
can do account linking.  It is non-reassignable so that the SP
ultimately gives access to the correct user.  If identifiers can be
reassigned...well, I think you can see the danger in that.  In
practice, if the IdP can guarantee non-reassignability for, say, six
months, we can deal with that.  We simply expire mappings older than
six months.

> is it still the DN from the user's certificate? or some other things?

Excuse for repeating myself, but the user does not possess an X.509
credential.  All the X.509 is hidden from the user.

> And it will be encrypted by what?

The persistent identifier asserted by the IdP is encrypted in the SAML
SSO assertion.  This is because we're gonna turn around and forward
this assertion to the grid.  The grid doesn't need to know the user's
campus identity, it only needs to know the user's local identity
(which is another reason to do account linking, by the way, so we can
control the identity asserted to the grid).

> > 3. The SP resolves local attributes and issues a local attribute
> > assertion with bound SSO assertion (in <Advice>).
>
> What is the scenario about local attribute? do you mean some role/group
> information which will be assigned to the user?

Exactly.  The grid portal, which is protected by the SP, creates
attributes for the user and binds those attributes to the user's local
identity.  For example, the user may join a Virtual Laboratory and by
doing so, a group membership is created.  The owner of the Virtual
Laboratory may delegate admin rights to this new user, and so a role
is created.  These memberships and roles are asserted to the grid
behind the portal.

When I described the Grid Use Case earlier, I neglected to describe
the Total Grid Use Case.  That's because what happens next is out of
scope for Shibboleth, so I didn't bother complicating the discussion
with grid-related details.  The basic idea is described in this wiki
topic:

https://spaces.internet2.edu/display/GS/NanoHUBTestbed

This topic is slightly out of date, but it should give you a fairly
good idea what happens behind the portal.  Anyway, if you have
detailed questions about the grid part, you should probably ask them
over on the GridShib lists.

Hope this helps,
Tom