Skip to Content.
Sympa Menu

shibboleth-dev - Re: [Shib-Dev] Principals in Session

Subject: Shibboleth Developers

List archive

Re: [Shib-Dev] Principals in Session


Chronological Thread 
  • From: Brent Putman <>
  • To:
  • Subject: Re: [Shib-Dev] Principals in Session
  • Date: Tue, 30 Nov 2010 15:49:59 -0500

Just had some time to follow-up on this.


On 11/24/10 1:23 PM, Paul Hethmon wrote:
>
>
> 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.


More below, but are you saying you are getting *only* the Shib
UsernamePrincipal? Or both your custom principal and the Shib one? I
believe both should be present in the Session Subject, in a standard
unmodified IdP. You said you modified yours, so maybe you're preserving
only 1, and it happens to be the Shib one.

>
> 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?


Yeah, I had to go look at this. I didn't think this was the case, but
turns out, the way the AuthenticationEngine code is written, it does
effectively do this, on the previous session handler. The previous
session handler does this:

httpRequest.setAttribute(LoginHandler.PRINCIPAL_NAME_KEY,
idpSession.getPrincipalName());

So returns just the principal name from the existing session (which in
your case would come from your custom principal, assuming no other login
handlers had previously run and populated the Subject with multiple
principals).

But then in the AuthenticationEngine, it does wind up creating a new
Shib UsernamePrincial from that "naked" principal name:

if (subject == null && (principal != null || principalName != null)) {
subject = new Subject();
if (principal == null) {
principal = new UsernamePrincipal(principalName);
}
subject.getPrincipals().add(principal);
}



So basically, after the previous session handler runs, you'll have both
your principal and the Shib UsernamePrincipal in the Session's Subject.
If you access that data from the session with Session#getPrincipalName,
you will in fact get the Shib one b/c the accessor code gives preference
to the Shib principal. That was to deal (partially and imperfectly)
with the issue outlined in SIDPT-38 (which will be dealt with in some
fashion in v3). Even if you don't have a Shib principal in there, but
do have multiple principals, you'd still not be guaranteed to get your
custom one, b/c of the random selection described in SIDPT-38.

So what you should really do in your data connector is use
Session#getSubject to get the entire session Subject and then obtain
your custom Principal directly from that. That way you always get the
one you want.

HTH,
Brent




Archive powered by MHonArc 2.6.16.

Top of Page