[Shib-Users] opensaml::FatalProfileException when logging in as a different user

[Dan McLaughlin]

We are seeing an issue after moving to SP 2.4 where the only way to
login with a different user, even after we logout of the SP, is to
close the browser. Is this the expected behavior? We have
ForcedAuthn enabled.

Steps to reproduce:

1) Login to the application using "User A" via a 2.4 SP & 2.2.x IDP
(using SAML2 Post) ForcedAuthn enabled.

2) Logout using https://www.mydomain.com/Shibboleth.sso/Logout

3) Without closing the browser, login to the same application as in
step 1, but use "User B". We are getting....

opensaml::FatalProfileException

The system encountered an error at Thu Mar 31 10:44:08 2011

To report this problem, please contact the site administrator at
help...@mydomain.com.

Please include the following message in any email:

opensaml::FatalProfileException at
(https://www.mydomain.com/Shibboleth.sso/SAML2/POST)

SAML response contained an error.

Error from identity provider:

Status: urn:oasis:names:tc:SAML:2.0:status:Responder
Sub-Status: urn:oasis:names:tc:SAML:2.0:status:AuthnFailed

4) Without closing the browser, login to the same application as in
step 1, but use "User A". We are logged in fine.

5) Now restart the browser, then login in to the same application as
in step 1, but use "User B". We are logged in fine.

--

Thanks,

Dan McLaughlin

NOTICE: This e-mail message and all attachments transmitted with it
are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is strictly prohibited. The contents of
this e-mail are confidential and may be subject to work product
privileges. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.

[Cantor, Scott E.]

On 4/6/11 10:45 PM, "Dan McLaughlin" <dmcla...@tech-consortium.com>
wrote:

>We are seeing an issue after moving to SP 2.4 where the only way to
>login with a different user, even after we logout of the SP, is to
>close the browser. Is this the expected behavior? We have
>ForcedAuthn enabled.

This has nothing to do with the SP, since the error is from the IdP.
AFAIK, the IdP has for a while disallowed switching users within a
session. Logging out of the SP has nothing to do with it obviously.
ForceAuthn is also irrelevant, the IdP is the one enforcing the policy.

So, no, this didn't happen because you upgraded the SP, it was true to
begin with.

-- Scott

[Sreejith K]

Hi All,

I am  getting following error in the IDP error log.

07:57:47.422 - INFO [Shibboleth-Access:73] - 20110406T115747Z|121.242.103.98|login.test.org:80|/profile/Shibboleth/SSO|
07:57:47.422 - WARN [edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSODecoder:71] - No providerId parameter given in Shibboleth SSO authentication request.
07:57:47.423 - WARN [edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSOProfileHandler:221] - Error decoding Shibboleth SSO request
org.opensaml.ws.message.decoder.MessageDecodingException: No providerId parameter given in Shibboleth SSO authentication request.
    at edu.internet2.middleware.shibboleth.idp.profile.saml1.ShibbolethSSODecoder.doDecode(ShibbolethSSODecoder.java:72) ~[shib

Can anybody tell me what can be the issue?

Thanks
Sreejith

[Peter Schober]

* Sreejith K <ksree...@gmail.com> [2011-04-07 09:16]:

> I am getting following error in the IDP error log.

You're hijacking someone else's thread, which messes up most archiving
software and some mail user agents. If you don't want to contribute to
an existing thread compose a new mail to the list, instead of just
replying to any existing mail from the list.

> Can anybody tell me what can be the issue?

Yes:

> - No providerId parameter given in Shibboleth SSO authentication request.

-peter

[Dan McLaughlin]

It's not the SP. Where we are having this issues is on workstations
that are shared by multiple users. Getting users to close the browser
after the SP logout has been a lost cause. The problem we are facing
is that the IdP is continuing to use the previous users IdP session
even though the SP is sending ForceAuthn="true" and the user is
authenticating successfully using a different user principal.

There error in the IdP log is...

14:39:53.189 - ERROR
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:553]
- Authentication failed with the error:
edu.internet2.middleware.shibboleth.idp.authn.ForceAuthenticationException:
Authenticated principal does not match previously authenticated
principal

Is there some other setting I can set on the IdP that will tell the
IdP to ignore the previous session and create a new one as long as
ForceAuthn=true and the user has successfully authenticated using a
new user principal?

--

Thanks,

Dan McLaughlin

NOTICE: This e-mail message and all attachments transmitted with it
are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is strictly prohibited. The contents of
this e-mail are confidential and may be subject to work product
privileges. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.

[Cantor, Scott E.]

On 6/6/11 3:48 PM, "Dan McLaughlin" <dmcla...@tech-consortium.com>
wrote:

>It's not the SP. Where we are having this issues is on workstations
>that are shared by multiple users. Getting users to close the browser
>after the SP logout has been a lost cause.

As is logout, so the options are fairly limited.

>The problem we are facing
>is that the IdP is continuing to use the previous users IdP session
>even though the SP is sending ForceAuthn="true" and the user is
>authenticating successfully using a different user principal.

There's nothing in the spec that implies forceAuthn means "change user".
It just means reauthenticate. The "re" part can plausibly be interpreted
as "same user". One reason is that changing user identity would play havoc
with the shared state being managed from the previous interactions. It
just doesn't work right once you open up that option.

>Is there some other setting I can set on the IdP that will tell the
>IdP to ignore the previous session and create a new one as long as
>ForceAuthn=true and the user has successfully authenticated using a
>new user principal?

I don't believe so.

A custom login handler, which is generally needed for deployments of any
serious nature using any non-trivial features *might* be able to do it,
but I suspect there are interactions that would need to be explored.

-- Scott

[Kevin P. Foote]

Would landing browser on a page which removes (hack) all browser cookies via javascript
create the desired effect here?? "Forcing" a new login request..

I don't know (never tried) just asking/thinking..

------
thanks
kevin.foote

On Mon, 6 Jun 2011, Cantor, Scott E. wrote:

-> On 6/6/11 3:48 PM, "Dan McLaughlin" <dmcla...@tech-consortium.com>
-> wrote:
-> >It's not the SP. Where we are having this issues is on workstations
-> >that are shared by multiple users. Getting users to close the browser
-> >after the SP logout has been a lost cause.
->
-> As is logout, so the options are fairly limited.
->
-> >The problem we are facing
-> >is that the IdP is continuing to use the previous users IdP session
-> >even though the SP is sending ForceAuthn="true" and the user is
-> >authenticating successfully using a different user principal.
->
-> There's nothing in the spec that implies forceAuthn means "change user".
-> It just means reauthenticate. The "re" part can plausibly be interpreted
-> as "same user". One reason is that changing user identity would play havoc
-> with the shared state being managed from the previous interactions. It
-> just doesn't work right once you open up that option.
->
-> >Is there some other setting I can set on the IdP that will tell the
-> >IdP to ignore the previous session and create a new one as long as
-> >ForceAuthn=true and the user has successfully authenticated using a
-> >new user principal?
->
-> I don't believe so.
->
-> A custom login handler, which is generally needed for deployments of any
-> serious nature using any non-trivial features *might* be able to do it,
-> but I suspect there are interactions that would need to be explored.
->
-> -- Scott
->
->

[Dan McLaughlin]

What about a way to disable the PreviousSession login handler based on
the SP? Or is there a way to have the SP request that the
PreviousSession login handler not be used?

--

Thanks,

Dan McLaughlin

NOTICE: This e-mail message and all attachments transmitted with it
are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is strictly prohibited. The contents of
this e-mail are confidential and may be subject to work product
privileges. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.

[Cantor, Scott E.]

On 6/6/11 4:22 PM, "Kevin P. Foote" <kpf...@iup.edu> wrote:
>Would landing browser on a page which removes (hack) all browser cookies
>via javascript
>create the desired effect here?? "Forcing" a new login request..

Pretty much (assuming you mean the IdP's domain, you can't magically blow
every domain's cookies away).

One problem is that the SPs wouldn¹t be able to prevent their own session
cookies from still working, so you'd end up with a mix of identities
unless you have a way to apply a short timeout and the forceAuthn option
on the SPs universally (and verify the time since login at each one).

That would also be true if the IdP were allowing user switching, of course.

I don't know what the answer is here, but it seems like cookies are just a
dead end for shared machines no matter how you slice it. I suppose that's
the one scenario where one could arguably implement front-channel logout
and get away with it, since you could lock down the browser config to
allow third party cookies to make a UI work.

-- Scott

[Dan McLaughlin]

Yes, but if the domain for the SP and IDP are different, then we don't
have access to the IdP session cookies.

Sounds more like I need a new allowChangeUser="true" feature to tell
the IdP it's okay to allow the user principle to change on a forced
authentication request.

--

Thanks,

Dan McLaughlin

NOTICE: This e-mail message and all attachments transmitted with it
are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is strictly prohibited. The contents of
this e-mail are confidential and may be subject to work product
privileges. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.

[Paul Hethmon]

ForceAuthn="true" is saying to not use PreviousSession.

On 6/6/11 4:24 PM, "Dan McLaughlin" <dmcla...@tech-consortium.com>

[Cantor, Scott E.]

On 6/6/11 4:24 PM, "Dan McLaughlin" <dmcla...@tech-consortium.com>
wrote:

>What about a way to disable the PreviousSession login handler based on
>the SP? Or is there a way to have the SP request that the
>PreviousSession login handler not be used?

That's what forceAuthn is. My memory of the code is that the user
switching block is not in the login handlers at all, but surrounding them,
because it's a function of preventing incoherence in the session.

The option you want only works if the IdP has no session or is prepared to
replace its session completely once the user switches and throw out the
old state. The IdP doesn't work that way right now. A custom login handler
and a very short lived IdP session can approximate it.

-- Scott

[Dan McLaughlin]

Unfortunately, we don't have the level of control over the IdP's to
enforce a custom handler, or a short lived IdP session. Is there a
way for the SP to request a specific IdP session timeout?

The other option I've thought about is changing the SP logout page so
that it prompts the user to close their browser to complete the
logout.

--

Thanks,

Dan McLaughlin

NOTICE: This e-mail message and all attachments transmitted with it
are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is strictly prohibited. The contents of
this e-mail are confidential and may be subject to work product
privileges. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.

[Dan McLaughlin]

You are correct for the SP, but it's not the case for the IdP.
Because the IdP doesn't support SLO, the only way to logout of the IdP
is the close all browser instances. So if you logout of the SP using
/Shibboleth.sso/Logout, then the ForcedAuthn will tell the SP to send
you back to the IdP for Authentication on any new requests, but if you
didn't close your browser before doing so then the IdP will look up
you previous session and require that you re-authenticate using the
original principle. You cannot login using a different user unless
you completely close your browser first.

--

Thanks,

Dan McLaughlin
Technology Consortium, LLC
dmcla...@tech-consortium.com
mobile: 512.633.8086
http://www.tech-consortium.com

NOTICE: This e-mail message and all attachments transmitted with it
are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is strictly prohibited. The contents of
this e-mail are confidential and may be subject to work product
privileges. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.

Need to schedule a meeting??? http://www.tungle.me/DanMcLaughlin

[Cantor, Scott E.]

On 6/6/11 4:47 PM, "Dan McLaughlin" <dmcla...@tech-consortium.com>
wrote:

>Unfortunately, we don't have the level of control over the IdP's to
>enforce a custom handler, or a short lived IdP session. Is there a
>way for the SP to request a specific IdP session timeout?

No.

-- Scott

[Christopher Bongaarts]

Dan McLaughlin wrote:
> Unfortunately, we don't have the level of control over the IdP's to
> enforce a custom handler, or a short lived IdP session. Is there a
> way for the SP to request a specific IdP session timeout?
>
> The other option I've thought about is changing the SP logout page so
> that it prompts the user to close their browser to complete the
> logout.

This is essentially what we've done for our SPs since we don't have the
SLO extension installed.

--
%% Christopher A. Bongaarts %% c...@umn.edu %%
%% OIT - Identity Management %% http://umn.edu/~cab %%
%% University of Minnesota %% +1 (612) 625-1809 %%

[Cantor, Scott E.]

On 6/6/11 5:26 PM, "Christopher Bongaarts" <c...@umn.edu> wrote:

>Dan McLaughlin wrote:
>> Unfortunately, we don't have the level of control over the IdP's to
>> enforce a custom handler, or a short lived IdP session. Is there a
>> way for the SP to request a specific IdP session timeout?
>>
>> The other option I've thought about is changing the SP logout page so
>> that it prompts the user to close their browser to complete the
>> logout.
>
>This is essentially what we've done for our SPs since we don't have the
>SLO extension installed.

When Dan said "they don't close the browser", I assumed that was with the
appropriate message included. In other words, I don't think they'll do it
anyway.

Presumably you know that Firefox as of v4 is horrendously broken with
respect to session restore, and now saves all cookies, including secure
ones, by default. The default could (and should) be changed in a locked
down client config of course.

It does make a lot of sense to trap the "user switch" error message (if
that gets reported to the client) and tell the user to close the browser
at that point, but a smart user will realize "hey, I bet I can try some
apps and get in as the last user".

-- Scott