Shibboleth Developers

[Adam Lantos <>]

Hello  -devs,

I want to call JAAS logout when the user logs out from the IdP. In
order to do this, I guess I have to retain the exact Subject the
module created.
There was a topic on shib-users which is somehow related to my
questions here:
http://marc.info/?l=shibboleth-users&m=124567220316751&w=2


Here is a proposal of a little change in the IdP API:

1, UsernamePasswordLoginServlet wouldn't create a new subject, it'd
pass LoginContext.getSubject() back. Only the
LoginContext.getPrincipals().add(new UsernamePrincipal()) method would
be called if no principals were present.

2, AuthenticationEngine.updateUserSession() would create a new
AuthenticationMethodInformation and pass the authenticationSubject,
not the merged session subject.

3, there is a deprecated getAuthenticationSubject() method in
AuthenticationMethodInformation interface, which could be used to
retrieve the exact subject the LoginModule created - so this method
wouldn't be deprecated any more - or probably a new method would be
created for this purpose, un-deprecat'ing methods ...

4, the AuthenticationMethodInformation needs to contain the necessary
information for the JAAS system. So the JAASConfigName would be passed
from the UsernamePasswordLoginServlet to the AuthenticationEngine and
bound to the AuthenticationMethodInformation there.


With these changes, the SLO code could loop through
AuthenticationMethodInformation objects and use the
getJAASConfigName() method to decide if it needs to call JAAS logout
or not (if the configName is not null, then it'd create a new JAAS
login context with the authenticationSubject and call the logout
method).


What do you think about it?


thanks,
 Adam


On Mon, Jun 22, 2009 at 2:03 PM, Chad La 
Joie<>
 wrote:
> There are a two main reasons.  Initially it was to keep around whatever the
> LoginModule put in to the context.  I did this because when the IdP supports
> SLO it should probably invoke the JAAS logout methods and I can't know which
> things a given LoginModule might need in order to support that.  Later on, a
> few individuals approached me with legitimate use cases for using the
> password within the resolver.
>
> That said, before Russ brought the issue to my attention, I had already
> started to add support, in 2.2, for dumping this information after
> authentication because I don't like keeping it around if it's not necessary.
>