Is this a correct aproach for managing SSO unpersistence

[Francisco Jose Fernandez Rivera]

Hello list,

I have in mind a SSO architecture based on Shibboleth. My firsts plans were to tell applications developers to develop one entry point capable to manage session attributes from the webserver (like REMOTE_USER carrying the authenticated principal), at the same time they have to be capable of maintaining their form login (user/password)

My idea was to make assertions expiry time very short, and delegate to the application the session management and also the logout/session finalization.

Basically what I want to get is that applications do not have to deal between shibboleth logout (SAML or Local) or logout in the application. This way I suppose I should only maintain one logout point (the application already existing one)

Exemplifying:

Application classical access point is:

www.aplication.com/<http://www.aplication.com/> (this shows a username/password form)

the SSO entry would be www.application.com/sso<http://www.application.com/sso> (this would be the only URL protected by SP). Once you have accessed the application via SSO (or login via IDP), you should get a valid application session and move around the app as if you had logged via username/password. And so the logout method would effectively logout from the application, and if the user tries to access again to the sso url, the IDP would show the authentication methods available.

I am not a web developer nor an application developer, hence my doubts. Is this a practical approach or am I forgetting some important point?

Thanks in advanced,

Francisco Fernández
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140203/90295284/attachment.html