Shibboleth Developers

[André Cruz <>]

On Oct 9, 2008, at 6:57 PM, Chad La Joie wrote:

> André Cruz wrote:
> > In this case I'm writing a LoginHandler.
> >
> > Regarding the LoginContext, I use it to know if forceAuth or  
> > isPassive
> > is requested. Is there other fields that I should take into account?
>
> Not that I can think of.  And you really shouldn't need to worry about
> those too unless you're integrating with an existing SSO system where
> you need to change the behavior of the system based on those settings.
> By default, as long as your handler truthfully reports if supports
> forceAuth and passive auth the IdP will take care of the rest.

You mean that if my LoginHandler does not implement isPassive or  
forceAuthn the IDP will "emulate" them for me? Because I want my IDP  
to support them.

What about the session that is created by the Authentication framework  
that we will use? For example,  with the RemoteUser login handler, we  
deploy a servlet filter to protect the RemoteUserAuthServlet. Normally  
this filter would check if the user is authenticated based on some  
session state, establish it if it doesn't exist, and fill REMOTE_USER  
with it before passing the execution to the servlet.

If a request with isPassive=true arrives, how does the IDP know it can  
use this LoginHandler without blocking? In other words, how does it  
know that a session exists? The same is true for ForceAuth. This  
LoginHandler would just use the existing session if it doesn't look at  
the LoginContext. Do we need to expose an endpoint to terminate it  
like the application sessions on the SP side?

Best regards,
André