Shibboleth Developers

[Chad La Joie <>]

After various discussions I have added a logout method to the 
AuthenticationHandler interface to all handlers to do whatever they may 
need to in order to destroy a user's session with the represented AuthN 
mechanism.  I also changed the "authenticate" method to "login" in order 
to be consistent.

This new method works the same as the login method, the request/response 
are passed to the handler, it does whatever it does, and then redirects 
back to the Authentication Manager.

Chad La Joie wrote:
> I've checked in what I believe to be a fairly complete interface for the 
> Shibboleth 2.0 Authentication Handlers:
>
> http://svn.middleware.georgetown.edu/view/trunk/src/edu/internet2/middleware/shibboleth/idp/authn/AuthenticationHandler.java?root=java-idp&view=markup 
>
>
> The interface is pretty simple and should allow easy inter-operation 
> with external authentication sources (e.g. container, Apache, other 
> SSOs).  The goal is to keep it simple too.
>
> The operation is fairly simple, the IdP will determine which handler to 
> invoke by looking at a lot of internal information (e.g. whether you've 
> authenticated before, when you did so, what type of criteria are present 
> on the incoming request, etc.) and if authentication is required it will 
> invoke the appropriate handler.  The appropriate handle is either the 
> one set as the default in the IdP config or the one corresponding to the 
> AuthnContext Class/Decl URI provided in the authentication request.
>
> Once the authentication method has been invoked the handler will have 
> complete control and may interact with the user however is necessary in 
> order to authenticate the user.  Once that is complete the handler (or 
> some other servlet/JSP it passed off to), must then forward the current 
> request/response pair backed to a location provided to the handler (via 
> setReturnLocation(String).
>
> The incoming request to the handler will contain the SAML 2 
> authentication request representing this request (even if the actual 
> system making the request is not a SAML 2 based system) within a request 
> attribute.  The handler must ensure the user's principal name is set in 
> a request attribute when it returns control back to the IdP.
>
> As I said, this should allow Shib 2.0 to be hooked in to any AuthN 
> environment that 1.3 currently works in.  We will ship, at least, a 
> forms based userid/password handler, a remote user based handler (that 
> works like Shib does now), and probably an IP based one.
>
> Comments/Questions?

--
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124