Shibboleth Developers

[Jim Fox <>]

This is what we added to shib 1.3 to get our EAuth idP up and running.
As Scott says, you can't make an idP without breaking a few classes.


------------
sessionreset
------------

EAuth permits an SP to require that a browser user re-authenticate
prior to being given credentials.  I don't know what that means in
all cases.  (If they authenticated with a certificate do they have
to get another one from the CA?)  In our case it means that they
have to retype a password.  To effect this capability we:

1) Leave the idP entry /shibboleth/HS unprotected by pubcookie.

2) 'Fix' E_AuthSSOHandler to get the remote_user out of a
   session cookie (JSESSIONID).

   a) If (sessionreset==1) delete pubcookie's session cookie.

   b) else if JSESSIONID has the userid use it.

   c) else redirect to:

       "/shibboleth/Login" if no sessionreset
       "/shibboleth/Relogin" if doing sessionreset

3) The servlet handling "Login" and "Relogin", which are protected
   by pubcookie, sets the userid in JSESSIONID and redirects to
   the original request, minus the sessionreset flag.  The URL
   "Login" requires only valid-user (actually membership in the
   appropriate eauth group).  The URL "Relogin" also includes
   pubcookie's directive to force re-authentication.



-----------
SubjectName
-----------

Out of the box, the only EAuth Subjectname DN is something like

   uid=<userid>,ou=...

where '<userid>' id the user's login name.  We (RL Bob actually) want
to use a targetedId here.  To do this:

1) We pretend to release targetedId to the SP (via arp).

2) After E_AuthSSOHandler computes the release attributes we
   retrieve the targetedID value from the attribute list and use
   it to make a new SubjectName.

3) Since we don't actually want to release the targetedId to the
   EAuth SP, we remove it from the attribute list.


-----------

That's about it.

Jim