Shibboleth Developers

[Peter Williams <>]

Title: Principals in Session

I cannot comment at all on Shib code, but perhaps can comment usefully on design and interworking issues as Ive seen them.

 

If I think about the code I read in the WIF/ASP.NET implementation (in which an IClaimsPrincipal and an IPrincipal address various types of Principal class), I half remember certain protocols influence how that framework’s API would deliver different principal types at different states of the invoked protocol itself. The class library had to address this, and address the multi-protocol nature of the world too.

 

In the case of Shib wire protocol (a superset of SAML protocols), the protocol itself defines the notion of “previous session”. Since this is a protocol-specific feature, id expect a principal type from the core framework to represent this notion in the API (such as a Shib principal class). Even if the initial authentication creates a custom Principal type by applying an API’s extensibility model (which enables the custom type to be signaled through the authnReq protocol as normal as some or other attribute contract), It makes sense that a ShibPrincipal would be indicated thru the API for the previous session flow case of the authnReq state machine. After all, the code for that set of state transitions knows nothing about the custom type. At the same time, I think Id expect that ShibPrincipal in that state to wrap the original custom type at the API (so [custom] end-user code that is in the know can go looking for it , once invoked).

 

I have to say until recently (during migration to WIF) we didn’t need to worry about such API design issues, since we were not using formal class identity libraries. (We used the rather simpler STS model over redirect bindings, in which SAML2 was only exposed at the bridging STS). In the simpler model of STS token exchanges, if the auth handlers in the IDP detected an existing webcookie, it could be configured to stuff the existingSession authnContext in custom-token given to the SAML STS/bridge. This would then generate the appropriate SAML response’s assertion and SAMl2 protocol behavior on the wire …suited to required semantics of previous session.

 

In interworking with at least 3 shib deployments (from different vendors using Shib libraries and components), I don’t think Ive ever encountered an SP that indicated previousSession in the sp-initiated AuthnReq, tho. And, none ever demanded in the interworking agreements that, as  an IDP, we should use previousSession as an authncontext. I suspect what would happen is that the IDP’s SAML2 server/bridge would perform all the handling, and never worry the upstream website responsible for user auth, or test it’s webcookies. Rather, it would use the STS-bridge cookie (for the active SAML sessionid controlling SSO/SLO) to control the response/assertion or otherwise indicate a suitable SAML error if unable to support previous session semantics.

 

Presumably, liberty interoperable profile tests address these kind of advanced cases, so natural and sensible things happen automatically.

 

If it’s useful to know, we have about 50 vendors in our SSO network, and about 5 are getting to the advanced use cases of SAML. Folks are thus starting to stress more of the protocol (and therefore invoke the interworking edge cases for such as previousSession). It’s clear the world is getting beyond the stage of just using SAML2 to trivially translate one web cookie into another. Folks are now wanting the more advanced “networking” semantics.

 

From: [mailto:] On Behalf Of Paul Hethmon
Sent: Wednesday, November 24, 2010 10:24 AM
To: Shibboleth Dev
Subject: [Shib-Dev] Principals in Session

 

A couple of months ago we had a thread here about storing a custom Principal in the session:

http://groups.google.com/group/shibboleth-dev/browse_thread/thread/a79b66fba144a071/a77ce1c16144f958?lnk=gst&q=data+connector#a77ce1c16144f958

I’ve pretty much got that working. Inside my login handler/servlet, I have my own Principal class that I give to the authentication engine once auth is complete. Then inside of my custom data connector, I pull out that Principal and resolve the attributes stored during the authentication sequence.

In the last couple of days, I’ve started working on getting this set up in a Terracotta clustered environment. Using TC 3.4.0.

Here’s the problem I’m running into. During the initial authentication, I get my Principal object. During a previous session authentication, I’m getting a Shib Principal object instead.

What I’m thinking is happening here is because of how I “changed” the authentication engine code to only store a single Principal (instead of multiple). That thought has just come up as I’m writing this. So, without my changes, would the previous session handler create a new Principal object and store it in the session? Even though the principal name is the same?

thanks,

Paul