shibboleth-dev - Re: Location of SP Session Cache
Subject: Shibboleth Developers
List archive
- From: André Cruz <>
- To:
- Subject: Re: Location of SP Session Cache
- Date: Wed, 6 Jun 2007 17:43:29 +0100
On 2007/06/06, at 16:31, Scott Cantor wrote:
The notes aren't public that I know of, they're unreadable in their raw form. If there's something you want to know, you can ask. Chances are if you're thinking that some aspect of it will be hard and require applications to do a lot of work (which they will not), you'd be right.
I'm guessing this only applies to applications that maintain their own sessions. These will have to implement a remote method that can be invoked to logout a specific user/session. What parameters will this method receive? Applications won't know NameIDs so will we be able to specify one of the user's attributes to be sent as a parameter to the logout URL of the application? Or maybe the REMOTE_USER (this may raise privacy issues for some)...
Only if the applications want to participate in the Single Logout will they need to implement it.. I don't have a problem with this.
So... When can we expect this to be developed? I had to implement a
I haven't made any secret of the fact that I think logout is generally unusable, so you can expect that it will be the last piece I write. I'm also hesitant to go very far with it until the IdP part is underway so I can make sure it fits together.
Other than the Application-maintained sessions what's the problem with the IdP notifying the SPs that a certain user's sessions are to be terminated? For me Single-Sign-On is just as important as Single- Sign-Out. It does not make sense to deploy one without the other. And as a lot of web applications need/want persistent sessions telling the users to close the browser is not an alternative.
The part that I need to do quickly is figuring out how I'm going to implement cache lookup by NameID. My guess is that's not going to work well, so I need to find that out sooner rather than later.
Humm.. Search for something not using the key with the Storage API? I'm guessing you'll have to maintain another storage just to relate sessionids and nameids. :)
Regards,
André
- Re: Shibboleth CAS LDAP Kerberos, (continued)
- Re: Shibboleth CAS LDAP Kerberos, Scott Cantor, 06/06/2007
- RE: Shibboleth CAS LDAP Kerberos, Lisa Tan, 06/06/2007
- Re: Shibboleth CAS LDAP Kerberos, Scott Cantor, 06/06/2007
- RE: Shibboleth CAS LDAP Kerberos, Lisa Tan, 06/07/2007
- Re: Shibboleth CAS LDAP Kerberos, Scott Cantor, 06/07/2007
- RE: Shibboleth CAS LDAP Kerberos, Lisa Tan, 06/07/2007
- Re: Shibboleth CAS LDAP Kerberos, Scott Cantor, 06/07/2007
- RE: Shibboleth CAS LDAP Kerberos, Lisa Tan, 06/07/2007
- Re: Shibboleth CAS LDAP Kerberos, Scott Cantor, 06/08/2007
- RE: Shibboleth CAS LDAP Kerberos, Lisa Tan, 06/08/2007
- RE: Shibboleth CAS LDAP Kerberos, Lisa Tan, 06/07/2007
- Re: Shibboleth CAS LDAP Kerberos, Scott Cantor, 06/06/2007
- RE: Shibboleth CAS LDAP Kerberos, Lisa Tan, 06/06/2007
- Re: Shibboleth CAS LDAP Kerberos, Scott Cantor, 06/06/2007
- Re: Location of SP Session Cache, Scott Cantor, 06/06/2007
- Re: Location of SP Session Cache, André Cruz, 06/07/2007
- Re: Location of SP Session Cache, Scott Cantor, 06/07/2007
- Re: Location of SP Session Cache, André Cruz, 06/07/2007
- Re: Location of SP Session Cache, Scott Cantor, 06/07/2007
- Re: Location of SP Session Cache, Scott Cantor, 06/07/2007
- Re: Location of SP Session Cache, André Cruz, 06/07/2007
- Re: Location of SP Session Cache, Scott Cantor, 06/07/2007
- Re: Location of SP Session Cache, André Cruz, 06/07/2007
- Re: Location of SP Session Cache, Scott Cantor, 06/07/2007
- Re: Location of SP Session Cache, André Cruz, 06/07/2007
- Re: Location of SP Session Cache, Scott Cantor, 06/10/2007
Archive powered by MHonArc 2.6.16.