What is replicated to the database-backed session store?

[Paul Hethmon]

It persists the Shib session object and whatever it might hold. I have to say I have not used attribute query so I'm not sure how it would be affected.

Paul

Paul Hethmon
Chief Software Architect
paul.hethmon at clareitysecurity.com


On Feb 5, 2014, at 12:28 PM, Nate Klingenstein <ndk at internet2.edu>
 wrote:

> So, I checked the blob in the database, and I do see the transient name identifier in there.  I assume that means the missing link is that the pc:Transient PrincipalConnector doesn't know how to check a database-backed session store and this is something that could probably be implemented (separately).
> 
> Or I screwed something up and the nodes are writing separately to the database(SSO and SLO are being managed by an external authentication mechanism) and not able to read each other's sessions but I don't think that's it...
> 
> On Feb 5, 2014, at 10:07 AM, Nate Klingenstein <ndk at internet2.edu>
> wrote:
> 
>> Users & particularly Paul,
>> 
>> I've got the database-backed session store writing sessions successfully to an Oracle DB.  Yay.  Thanks for the work on the packaging.
>> 
>> However, when an attribute query (SAML 1.1 or SAML 2.0) based on a transient NameID is assigned to a node that is not the original node that the user authenticated to, it fails the lookup and can't respond to the query.  The query succeeds when it lands on the original node.
>> 
>> So, what exactly is replicated to the database and what does it enable?  Is this just enabling SSO and SLO?  Artifact resolution?  Attribute queries?
>> 
>> Thanks,
>> Nate.
>> --
>> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net