Fail to authenticate user - Redirecting to login page /login.jsp
Gilles Badouet
badouetg at uni.coventry.ac.uk
Wed Jul 31 15:26:01 EDT 2013
What does 'No login context in storage service',
'No relying party, nothing to display' mean after an authentication failure?
When using another browser than IE, I cant see the above messages anymore in logs. Instead, I just see:
Failed to authenticate user
DEBUG [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:150] - Redirecting to login page /login.jsp
All is ok with the SP, no problem in logs and the result of shibd -check does not present any error.
What is going wrong within my configs and which file(e) may be concerned?
Is there any compatibility point related to the problem in windows server 2003 i am now using , or can a program prevent the IdP to perform well its operations?
Thank you
Gilles Rubens Badouet
________________________________________
From: users-bounces at shibboleth.net <users-bounces at shibboleth.net> on behalf of users-request at shibboleth.net <users-request at shibboleth.net>
Sent: 31 July 2013 17:31
To: users at shibboleth.net
Subject: users Digest, Vol 25, Issue 141
Send users mailing list submissions to
users at shibboleth.net
To subscribe or unsubscribe via the World Wide Web, visit
http://shibboleth.net/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
users-request at shibboleth.net
You can reach the person managing the list at
users-owner at shibboleth.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."
Today's Topics:
1. RE: Fail to log in (Gilles Badouet)
2. Re: leveraging login context expiration on login form
(Christopher Bongaarts)
3. Re: Occasional SAML exception during SP/IdP handshake
(Cantor, Scott)
----------------------------------------------------------------------
Message: 1
Date: Wed, 31 Jul 2013 16:06:19 +0000
From: Gilles Badouet <badouetg at uni.coventry.ac.uk>
Subject: RE: Fail to log in
To: "users at shibboleth.net" <users at shibboleth.net>
Message-ID:
<67025a40d3c7434589ba2ac80c23ece2 at DB3PR01MB025.eurprd01.prod.exchangelabs.com>
Content-Type: text/plain; charset="us-ascii"
> 15:09:48.863 - DEBUG
> [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:194]
> - User authentication for xxx failed
>The next line in your log should be a stack trace which hopefully will
>provide more information.
Hi Tom,
Below is a more complete log:
17:03:43.288 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:170] - Attempting to authenticate user mama
17:03:43.288 - DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:180] - useFirstPass = false
17:03:43.288 - DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:181] - tryFirstPass = false
17:03:43.288 - DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:182] - storePass = false
17:03:43.288 - DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:183] - clearPass = false
17:03:43.288 - DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:184] - setLdapPrincipal = true
17:03:43.288 - DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:185] - setLdapDnPrincipal = false
17:03:43.288 - DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:186] - setLdapCredential = true
17:03:43.288 - DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:187] - defaultRole = []
17:03:43.288 - DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:188] - principalGroupName = null
17:03:43.288 - DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:189] - roleGroupName = null
17:03:43.288 - DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:77] - userRoleAttribute = []
17:03:43.288 - DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:83] - Created authenticator: edu.vt.middleware.ldap.auth.AuthenticatorConfig at 5867073::env={java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, principal=cn=Directory Manager, LdapUrl=ldap://lonfp2.ans.local:389, ServiceCredential=shibans}
17:03:43.288 - DEBUG [edu.vt.middleware.ldap.auth.SearchDnResolver:108] - Looking up DN using userField
17:03:43.303 - DEBUG [edu.vt.middleware.ldap.auth.SearchDnResolver:193] - Search with the following parameters:
17:03:43.303 - DEBUG [edu.vt.middleware.ldap.auth.SearchDnResolver:194] - dn = ou=People,dc=example,dc=com
17:03:43.303 - DEBUG [edu.vt.middleware.ldap.auth.SearchDnResolver:195] - filter = (uid={0})
17:03:43.303 - DEBUG [edu.vt.middleware.ldap.auth.SearchDnResolver:196] - filterArgs = [mama]
17:03:43.303 - DEBUG [edu.vt.middleware.ldap.auth.SearchDnResolver:197] - searchControls = javax.naming.directory.SearchControls at 17d25fe
17:03:43.303 - DEBUG [edu.vt.middleware.ldap.auth.SearchDnResolver:198] - handler = [edu.vt.middleware.ldap.handler.FqdnSearchResultHandler at 149728b]
17:03:43.303 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:194] - User authentication for mama failed
javax.security.auth.login.LoginException: java.lang.NullPointerException
at java.util.Hashtable.put(Unknown Source)
at edu.vt.middleware.ldap.handler.AbstractConnectionHandler.connect(AbstractConnectionHandler.java:149)
at edu.vt.middleware.ldap.AbstractLdap.connect(AbstractLdap.java:1006)
at edu.vt.middleware.ldap.AbstractLdap.getContext(AbstractLdap.java:1058)
at edu.vt.middleware.ldap.AbstractLdap.search(AbstractLdap.java:214)
at edu.vt.middleware.ldap.auth.SearchDnResolver.resolve(SearchDnResolver.java:139)
at edu.vt.middleware.ldap.auth.Authenticator.getDn(Authenticator.java:106)
at edu.vt.middleware.ldap.jaas.JaasAuthenticator.authenticate(JaasAuthenticator.java:74)
at edu.vt.middleware.ldap.auth.Authenticator.authenticate(Authenticator.java:320)
at edu.vt.middleware.ldap.auth.Authenticator.authenticate(Authenticator.java:277)
at edu.vt.middleware.ldap.jaas.JaasAuthenticator.authenticate(JaasAuthenticator.java:60)
at edu.vt.middleware.ldap.jaas.LdapLoginModule.login(LdapLoginModule.java:103)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.access$000(Unknown Source)
at javax.security.auth.login.LoginContext$4.run(Unknown Source)
at javax.security.auth.login.LoginContext$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(Unknown Source)
at javax.security.auth.login.LoginContext.login(Unknown Source)
at edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet.authenticateUser(UsernamePasswordLoginServlet.java:177)
at edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet.service(UsernamePasswordLoginServlet.java:123)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at edu.internet2.middleware.shibboleth.idp.util.NoCacheFilter.doFilter(NoCacheFilter.java:50)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter.doFilter(IdPSessionFilter.java:87)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at edu.internet2.middleware.shibboleth.common.log.SLF4JMDCCleanupFilter.doFilter(SLF4JMDCCleanupFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Unknown Source)
at javax.security.auth.login.LoginContext.invoke(Unknown Source) ~[na:1.7.0_25]
at javax.security.auth.login.LoginContext.access$000(Unknown Source) ~[na:1.7.0_25]
at javax.security.auth.login.LoginContext$4.run(Unknown Source) ~[na:1.7.0_25]
at javax.security.auth.login.LoginContext$4.run(Unknown Source) ~[na:1.7.0_25]
at java.security.AccessController.doPrivileged(Native Method) ~[na:1.7.0_25]
at javax.security.auth.login.LoginContext.invokePriv(Unknown Source) ~[na:1.7.0_25]
at javax.security.auth.login.LoginContext.login(Unknown Source) ~[na:1.7.0_25]
at edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet.authenticateUser(UsernamePasswordLoginServlet.java:177) [shibboleth-identityprovider-2.4.0.jar:na]
at edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet.service(UsernamePasswordLoginServlet.java:123) [shibboleth-identityprovider-2.4.0.jar:na]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) ~[servlet-api.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) ~[catalina.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) ~[catalina.jar:na]
at edu.internet2.middleware.shibboleth.idp.util.NoCacheFilter.doFilter(NoCacheFilter.java:50) ~[shibboleth-identityprovider-2.4.0.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) ~[catalina.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) ~[catalina.jar:na]
at edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter.doFilter(IdPSessionFilter.java:87) ~[shibboleth-identityprovider-2.4.0.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) ~[catalina.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) ~[catalina.jar:na]
at edu.internet2.middleware.shibboleth.common.log.SLF4JMDCCleanupFilter.doFilter(SLF4JMDCCleanupFilter.java:52) ~[shibboleth-common-1.4.0.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) ~[catalina.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) ~[catalina.jar:na]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219) ~[catalina.jar:na]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) ~[catalina.jar:na]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) ~[catalina.jar:na]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) ~[catalina.jar:na]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) ~[catalina.jar:na]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) ~[catalina.jar:na]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) ~[tomcat-coyote.jar:na]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) ~[tomcat-coyote.jar:na]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) ~[tomcat-coyote.jar:na]
at java.lang.Thread.run(Unknown Source) ~[na:1.7.0_25]
17:03:43.303 - DEBUG [edu.internet2.middleware.shibboleth.idp.util.HttpServletHelper:360] - No login context in storage service
17:03:43.303 - DEBUG [edu.internet2.middleware.shibboleth.idp.ui.ServiceTagSupport:372] - No relying party, nothing to display
17:03:43.303 - DEBUG [edu.internet2.middleware.shibboleth.idp.util.HttpServletHelper:360] - No login context in storage service
17:03:43.303 - DEBUG [edu.internet2.middleware.shibboleth.idp.util.HttpServletHelper:360] - No login context in storage service
17:03:43.303 - DEBUG [edu.internet2.middleware.shibboleth.idp.util.HttpServletHelper:360] - No login context in storage service
17:03:43.303 - DEBUG [edu.internet2.middleware.shibboleth.idp.ui.ServiceDescriptionTag:93] - No relying party, nothing to display
17:03:43.303 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:150] - Redirecting to login page /login.jsp
Kind regards
Gilles Rubens Badouet
________________________________________
From: users-bounces at shibboleth.net <users-bounces at shibboleth.net> on behalf of users-request at shibboleth.net <users-request at shibboleth.net>
Sent: 31 July 2013 17:00
To: users at shibboleth.net
Subject: users Digest, Vol 25, Issue 140
Send users mailing list submissions to
users at shibboleth.net
To subscribe or unsubscribe via the World Wide Web, visit
http://shibboleth.net/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
users-request at shibboleth.net
You can reach the person managing the list at
users-owner at shibboleth.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."
Today's Topics:
1. Re: Fail to log in (Tom Zeller)
2. leveraging login context expiration on login form
(Christopher Bongaarts)
3. Re: login.config to use private-CA-issued certificate
(Peter Schober)
4. Re: leveraging login context expiration on login form
(Cantor, Scott)
5. Re: Occasional SAML exception during SP/IdP handshake
(Saimon Moore)
----------------------------------------------------------------------
Message: 1
Date: Wed, 31 Jul 2013 09:45:33 -0500
From: Tom Zeller <tzeller at dragonacea.biz>
Subject: Re: Fail to log in
To: Shib Users <users at shibboleth.net>
Message-ID:
<CAMNmQDSkT9djic-WowoPY4=V4BEu0L=sp0h3G3M3u88xWKCGjQ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
> What can be the reason of the following issue when I enter a user
> credentials in the IdP authentication page?
>
> 15:09:48.863 - DEBUG
> [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:194]
> - User authentication for xxx failed
The next line in your log should be a stack trace which hopefully will
provide more information.
------------------------------
Message: 2
Date: Wed, 31 Jul 2013 10:06:00 -0500
From: Christopher Bongaarts <cab at umn.edu>
Subject: leveraging login context expiration on login form
To: users at shibboleth.net
Message-ID: <51F927D8.7060701 at umn.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Before I go RTFS I thought I'd see if anyone already has the answer handy...
Is there a way, from within login.jsp, to get the time (preferably in
UNIX time_t but any format will do) that the current loginContext will
expire? A cursory examination of the methods of loginContext didn't
reveal anything obvious.
The goal is to pass this time as a parameter to a page on another site,
so the other site can make an educated guess whether returning the user
to the IdP will allow them to continue their login process, or if it is
likely to blow up.
--
%% Christopher A. Bongaarts %% cab at umn.edu %%
%% OIT - Identity Management %% http://umn.edu/~cab %%
%% University of Minnesota %% +1 (612) 625-1809 %%
------------------------------
Message: 3
Date: Wed, 31 Jul 2013 17:11:08 +0200
From: Peter Schober <peter.schober at univie.ac.at>
Subject: Re: login.config to use private-CA-issued certificate
To: users at shibboleth.net
Message-ID: <20130731151108.GA9782 at aco.net>
Content-Type: text/plain; charset=us-ascii
* David Bantz <dabantz at alaska.edu> [2013-07-31 01:48]:
> (B) may be infeasible unless there is some way to include reference
> to multiple trusted server certificates (non-obviousi to me).
You said those server certs were issued by a private CA, I'm assuming
the same one. Why not add that private CA as a trust anchor (via
whatever mechanism) instead of adding server certs, which will break
the next time someone decides to roll over a server cert (probably
without telling you)?
-peter
------------------------------
Message: 4
Date: Wed, 31 Jul 2013 15:20:43 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
Subject: Re: leveraging login context expiration on login form
To: Shib Users <users at shibboleth.net>
Message-ID:
<BA63CEAE152A7742B854C678D9491383AD13707B at CIO-KRC-D1MBX01.osuad.osu.edu>
Content-Type: text/plain; charset="us-ascii"
On 7/31/13 11:06 AM, "Christopher Bongaarts" <cab at umn.edu> wrote:
>Is there a way, from within login.jsp, to get the time (preferably in
>UNIX time_t but any format will do) that the current loginContext will
>expire? A cursory examination of the methods of loginContext didn't
>reveal anything obvious.
It's not stored there, there's an Entry object around it that carries the
value. It's quite long, apparently, a half hour. I wouldn't have expected
that.
-- Scott
------------------------------
Message: 5
Date: Wed, 31 Jul 2013 17:38:10 +0200
From: Saimon Moore <saimonmoore at gmail.com>
Subject: Re: Occasional SAML exception during SP/IdP handshake
To: Shib Users <users at shibboleth.net>
Message-ID:
<CAEo1HV7PMq06ZgOcT5fzYSE9_k9dM--WGLybTp87F-RyUn3x_Q at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Scott,
I put on my thinking cap and realised that I had forceAuthn set to true in
shib2.xml config and this is why the existing session wasn't be reused.
So in reality I was asking the idp to reauthenticate while an existing
session already existed. It may be that the IdP has an issue with this when
the session cookies exist for the user retrying the authentication.
For us this solution is good enough.
I completely missed this attribute in my previous investigations.
Thanks and sorry for the noise.
On Wed, Jul 31, 2013 at 4:41 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 7/31/13 10:25 AM, "Saimon Moore" <saimonmoore at gmail.com> wrote:
>
> >I did some further debugging and this only happens if I reattempt auth
> >via shibboleth after a previous successfull login (via shibboleth).
> >
> >If I don't completely clear all my session cookies I always get the
> >exception above. If I do clear session cookies then I don't get the
> >exception.
>
> There is nothing like what you described under ordinary use.
>
> >I'm unsure wether this issue is due to the existing session in the SP or
> >in the IdP.
>
> The SP has nothing whatsoever to do with this.
>
> >If in the IdP is there a url IdP's have I can redirect users to
> >invalidate the IdP Session (for my SP only) there?
>
> That also has nothing to do with this.
>
> Request processing at the IdP is up to the IdP. If you send it requests
> that result in a protocol failure, that's that. What's causing the error
> is up to the IdP admin to look into and resolve if it's not caused by
> something the SP is sending it. AuthnFailed in general means that there's
> a login handler acting improperly or being used improperly and isn't able
> to handle the login process.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
--
Saimon Moore
Web Developer @ Teambox.com
(http://teambox.com)
Skype: saimonmoore
Yahoo IM: saimonmoore
Google IM: saimonmoore
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130731/ea58e98a/attachment-0001.html
------------------------------
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
End of users Digest, Vol 25, Issue 140
**************************************
------------------------------
Message: 2
Date: Wed, 31 Jul 2013 11:13:09 -0500
From: Christopher Bongaarts <cab at umn.edu>
Subject: Re: leveraging login context expiration on login form
To: users at shibboleth.net
Message-ID: <51F93795.7030600 at umn.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 7/31/2013 10:20 AM, Cantor, Scott wrote:
> On 7/31/13 11:06 AM, "Christopher Bongaarts"<cab at umn.edu> wrote:
>
>> >Is there a way, from within login.jsp, to get the time (preferably in
>> >UNIX time_t but any format will do) that the current loginContext will
>> >expire? A cursory examination of the methods of loginContext didn't
>> >reveal anything obvious.
> It's not stored there, there's an Entry object around it that carries the
> value. It's quite long, apparently, a half hour. I wouldn't have expected
> that.
OK, so unless there's some secret shortcut, I'll just copy+paste the
guts of HttpServletHelper.getLoginContext() into my jsp and call
getExpirationTime() on the entry object.
--
%% Christopher A. Bongaarts %% cab at umn.edu %%
%% OIT - Identity Management %% http://umn.edu/~cab %%
%% University of Minnesota %% +1 (612) 625-1809 %%
------------------------------
Message: 3
Date: Wed, 31 Jul 2013 16:30:27 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
Subject: Re: Occasional SAML exception during SP/IdP handshake
To: Shib Users <users at shibboleth.net>
Message-ID:
<BA63CEAE152A7742B854C678D9491383AD137140 at CIO-KRC-D1MBX01.osuad.osu.edu>
Content-Type: text/plain; charset="us-ascii"
On 7/31/13 11:38 AM, "Saimon Moore" <saimonmoore at gmail.com> wrote:
>
>I put on my thinking cap and realised that I had forceAuthn set to true
>in shib2.xml config and this is why the existing session wasn't be reused.
If their login handler chosen does not support ForceAuthn, then the IdP is
behaving correctly by returning the error.
>So in reality I was asking the idp to reauthenticate while an existing
>session already existed. It may be that the IdP has an issue with this
>when the session cookies exist for the user retrying the authentication.
No, the issue is they use a login handler that doesn't happen to support
the option. Many will not.
-- Scott
------------------------------
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
End of users Digest, Vol 25, Issue 141
**************************************
More information about the users
mailing list