Fail to authenticate user - Redirecting to login page /login.jsp
Gilles Badouet
badouetg at uni.coventry.ac.uk
Wed Jul 31 16:04:21 EDT 2013
>None of that addresses the failure in the LDAP module. An NPE is a bug of
>some kind, but most likely the login.config is malformed in some subtle
>unusual way.
Hi Scott,
I suppose stop using IE at the moment and would like to first sort out the issue of the failure to authenticate-Redirecting to login page /login.jsp
when using another browser.
I have checked my login.config and it s ok.
Where can I diagnose further?
Within the LDAP log, it also shows the failure to authenticate the user (-- client unbind).
I did about the same implementation scenario few days ago within 2 windows 7 (SP and Idp) and all worked. I am now repeating almost the same scenario within windows server 2008 (SP) and windows server 2003 (IdP), both in the same local domain. In addition , I modified the logout.jsp (but only the logo and texts to be displayed).
Kind regards
Gilles Rubens Badouet
Student ID: 3940347
Faculty of Engineering and Computing
MSc Network Computing Course
Mobile: 07424486426
________________________________________
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 20:34
To: users at shibboleth.net
Subject: users Digest, Vol 25, Issue 143
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 authenticate user - Redirecting to login page
/login.jsp (Paul Hethmon)
2. Re: Fail to authenticate user - Redirecting to login page
/login.jsp (Cantor, Scott)
----------------------------------------------------------------------
Message: 1
Date: Wed, 31 Jul 2013 19:33:27 +0000
From: Paul Hethmon <paul.hethmon at clareitysecurity.com>
Subject: Re: Fail to authenticate user - Redirecting to login page
/login.jsp
To: Shib Users <users at shibboleth.net>
Message-ID: <CE1EDDFB.3906F%paul.hethmon at clareitysecurity.com>
Content-Type: text/plain; charset="us-ascii"
One thing to check for is that the client browser is not submitting the
login page multiple times. I've seen this on satellite internet providers
especially where the form submission will happen twice. Shib processes the
first submission and kills the login context (since it is done with it).
However, the browser has already closed that socket on its end. The second
submission of the login form will get errors similar to what you are
reporting.
Check your Tomcat access logs and see if you can pick out multiple
submissions. Recording the real IP address and recording the Tomcat
JSESSIONID value in the logs is very helpful to track this down.
It might not be this, but worth checking.
Paul
On 7/31/13 3:26 PM, "Gilles Badouet" <badouetg at uni.coventry.ac.uk> wrote:
>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.UsernamePasswordLo
>ginServlet: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.UsernamePasswordL
>>oginServlet: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.UsernamePasswordLo
>ginServlet: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.UsernamePasswordLo
>ginServlet: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(AbstractC
>onnectionHandler.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(JaasAuthenticat
>or.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(JaasAuthenticat
>or.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.UsernamePasswordLog
>inServlet.authenticateUser(UsernamePasswordLoginServlet.java:177)
> at
>edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLog
>inServlet.service(UsernamePasswordLoginServlet.java:123)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> at
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
>onFilterChain.java:290)
> at
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
>Chain.java:206)
> at
>edu.internet2.middleware.shibboleth.idp.util.NoCacheFilter.doFilter(NoCach
>eFilter.java:50)
> at
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
>onFilterChain.java:235)
> at
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
>Chain.java:206)
> at
>edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter.doFilter(
>IdPSessionFilter.java:87)
> at
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
>onFilterChain.java:235)
> at
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
>Chain.java:206)
> at
>edu.internet2.middleware.shibboleth.common.log.SLF4JMDCCleanupFilter.doFil
>ter(SLF4JMDCCleanupFilter.java:52)
> at
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
>onFilterChain.java:235)
> at
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
>Chain.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:1
>28)
> at
>org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:1
>02)
> at
>org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.ja
>va: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(Ht
>tp11Protocol.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.UsernamePasswordLog
>inServlet.authenticateUser(UsernamePasswordLoginServlet.java:177)
>[shibboleth-identityprovider-2.4.0.jar:na]
> at
>edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLog
>inServlet.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(Applicati
>onFilterChain.java:290) ~[catalina.jar:na]
> at
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
>Chain.java:206) ~[catalina.jar:na]
> at
>edu.internet2.middleware.shibboleth.idp.util.NoCacheFilter.doFilter(NoCach
>eFilter.java:50) ~[shibboleth-identityprovider-2.4.0.jar:na]
> at
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
>onFilterChain.java:235) ~[catalina.jar:na]
> at
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
>Chain.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(Applicati
>onFilterChain.java:235) ~[catalina.jar:na]
> at
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
>Chain.java:206) ~[catalina.jar:na]
> at
>edu.internet2.middleware.shibboleth.common.log.SLF4JMDCCleanupFilter.doFil
>ter(SLF4JMDCCleanupFilter.java:52) ~[shibboleth-common-1.4.0.jar:na]
> at
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
>onFilterChain.java:235) ~[catalina.jar:na]
> at
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
>Chain.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:1
>28) ~[catalina.jar:na]
> at
>org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:1
>02) ~[catalina.jar:na]
> at
>org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.ja
>va: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(Ht
>tp11Protocol.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.UsernamePasswordLo
>ginServlet: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.UsernamePasswordL
>>oginServlet: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/attach
>ment-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
>**************************************
>
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net
------------------------------
Message: 2
Date: Wed, 31 Jul 2013 19:33:34 +0000
From: "Cantor, Scott" <cantor.2 at osu.edu>
Subject: Re: Fail to authenticate user - Redirecting to login page
/login.jsp
To: Shib Users <users at shibboleth.net>
Message-ID:
<BA63CEAE152A7742B854C678D9491383AD137627 at CIO-KRC-D1MBX01.osuad.osu.edu>
Content-Type: text/plain; charset="us-ascii"
Please stop top quoting huge threads or digests.
On 7/31/13 3:26 PM, "Gilles Badouet" <badouetg at uni.coventry.ac.uk> wrote:
>What does 'No login context in storage service',
> 'No relying party, nothing to display' mean
>after an authentication failure?
The cookie that tracks the state of the login process is missing or
something has destroyed the context in between steps. I don't know how you
have managed to make that happen.
>When using another browser than IE, I cant see the above messages anymore
>in logs. Instead, I just see:
Then your IE browser is misbehaving in some way or isn't accepting cookies.
None of that addresses the failure in the LDAP module. An NPE is a bug of
some kind, but most likely the login.config is malformed in some subtle
unusual way.
-- Scott
------------------------------
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
End of users Digest, Vol 25, Issue 143
**************************************
More information about the users
mailing list