Shibboleth v3 - Session HA Questions
prasannacgin at yahoo.in
Wed Jul 1 19:50:19 UTC 2020
Thanks Scott. I understand I am missing something here. Let me look further. Also, Is there a way to create a new / fresh "sealer.jks" and “sealer.kver” files in an IDP node ? I am trying to see if I can ignore the ones that exist now and create a new file for each of my IDP nodes and test again.
> On Jul 1, 2020, at 2:13 PM, prasanna cg <prasannacgin at yahoo.in> wrote:
> I am new to Shibboleth IDP and have questions related to session clustering. Requesting for expert’s opinion / help
> My Current Set-up :
> > Deployment: F5 LB VIP (idp.example.com <http://idp.example.com/>) ; IDP1 (server1.example.com <http://server1.example.com/>) ; IDP2 (server2.example.com <http://server2.example.com/>)
> > IDP Servers: Apache HTTP Server <=> Tomcat Container
> > Clustering: IDP Nodes are independent and are not clustered; LB is set-up in Active:Passive configuration
> > Cookie Encryption SecretKey are not shared between the IDP nodes
> Behavior I am noticing:
> 1) Access an IDP Init SSO URL (https://idp.example.com/idp/profile/SAML2/Unsolicited/SSO?providerId=XXX <https://idp.example.com/idp/profile/SAML2/Unsolicited/SSO?providerId=XXX>).
> 2) Perform user authentication and got the IDP Session established in IDP1
> 2) Shutdown IDP1 thereby letting the traffic go to IDP2
> 3) In same browser, access the IDP Init SSO URL again that goes to IDP2 via the F5
> 4) Getting seamless SSO (without user authentication)
> 5) Override DNS resolver in localhost file by adding a server from completely a different IDP (lets say IDPx) environment to resolve to “idp.example.com <http://idp.example.com/>”
> 6) In same browser, access the IDP Init SSO URL again that resolves to this new IDPx
> 7) Getting seamless SSO (without user authentication)
> NOTE: My datasealer store password is common across all IDPs
> What I read and understood:
> From this IDPv3 Clustering link - https://wiki.shibboleth.net/confluence/display/IDP30/SecretKeyManagement <https://wiki.shibboleth.net/confluence/display/IDP30/SecretKeyManagement>, all I understood is that the IDP nodes supports Session HA between nodes only if the Cookie Encryption Secret Key is shared between the IDP nodes that are required to be in a cluster. Else my understanding is - a user will be forced to re-authenticate when another node takes the request in spite of having a valid session cookie
> 1) Is this behavior expected ? Am I missing something ?
> 2) If yes,
> a) then, what is the need for sharing the secret key between IDP nodes ?
> b) is this a good security (especially the behavior #5 to 7)
> 3) If no,
> a) what could be the reason for this behavior ?
> b) should I consider having different passwords between IDP environments ?
> Please help me understand !
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users