[Shib-Users] SSO Failing
Paul Hethmon
I’ve traced both paths using FF with Live Headers. I’m not seeing a difference there. I see the IdP cookie being set on successful authentication and I see the same value being returned on the second access.
I’ve turned up the IdP logging to DEBUG including the protocol messages. I haven’t seen anything there. I have noticed that the .NET SP sends its requests as HTTP-Redirect while the Shib SP’s send theirs as HTTP-POST. As as side note, it seems that HTTP-POST does not log the protocol messages at DEBUG level. Haven’t checked code yet on that, but I see the AuthnRequests for Redirect in idp-process.log but not for POST.
I did check for ForceAuthn in the inbound requests and actually do see some come in with it set to true. In my test cases though, I don’t see it come in as true. At least if I’m correlating correctly. I’ve been doing this testing over the last hour or so, so traffic is light and I have a reasonable belief my reading of the logs is right.
If someone has any suggestions for something to look for, I would appreciate it.
Thanks,
Paul
-----
Paul Hethmon
Chief Software Architect
Clareity Security, LLC
865.824.1350 - office
865.250.3517 - mobile
www.clareitysecurity.com
-----
Give a man a fire and he's warm for the day. But set fire to him and he's warm for the rest of his life.
-- Terry Pratchett, Discworld
Paul Hethmon
Let me add some additional weirdness. First, label the two Shib protected SPs as A and B. Label the .NET protected SP as N. If I follow this path:
Access A -> asked to login
Access B -> asked to login
Access N -> not asked to login (previous session used)
Alternate path:
Access N -> asked to login
Access A -> not asked
Access B -> not asked
Alternate path:
Access B -> asked to login
Access A -> not asked
Access N -> not asked
Alternate path:
Access A -> asked to login
Access N -> asked to login
Access B -> not asked to
It seems I have a problem when authenticating based on accessing SP A. Given that, here’s the AuthnRequest as captured in the log: (hostnames changed to protect the guilty)
<?xml version="1.0" encoding="UTF-8"?><samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="http://a.example.com/Shibboleth.sso/SAML2/POST" Destination="https://idp.example.com/idp/profile/SAML2/Redirect/SSO" ID="_3fac6b6a01b03051ffdb1ecd014df017" IssueInstant="2009-04-23T04:40:10Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://a.example.com/shibboleth-sp</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="1"/>
</samlp:AuthnRequest>
Here’s the response in the log:
<?xml version="1.0" encoding="UTF-8"?><samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Destination="http://a.example.com/Shibboleth.sso/SAML2/POST" ID="_7c26e7bd72bf5193266db6a6caa07b14" InResponseTo="_3fac6b6a01b03051ffdb1ecd014df017" IssueInstant="2009-04-23T04:40:19.676Z" Version="2.0">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idp.example.com/idp/shibboleth</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>(deleted to save message space)
</ds:SignedInfo>
<ds:SignatureValue>(d)
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>(deleted)</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_984a290ec3bbc97a066cceb00108a266" IssueInstant="2009-04-23T04:40:19.676Z" Version="2.0">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idp.example.com/idp/shibboleth</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:clareity:safemls:nameid-format:loginid">ed</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData Address="192.168.5.7" InResponseTo="_3fac6b6a01b03051ffdb1ecd014df017" NotOnOrAfter="2009-04-23T04:45:19.676Z" Recipient="http://a.example.com/Shibboleth.sso/SAML2/POST"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2009-04-23T04:40:19.676Z" NotOnOrAfter="2009-04-23T04:45:19.676Z">
<saml:AudienceRestriction>
<saml:Audience>http://a.example.com/shibboleth-sp</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2009-04-23T04:40:19.661Z" SessionIndex="63007084d615432e28cebeb6d18fee29bad57d0ed2829e4141d8b2259b32c300">
<saml:SubjectLocality Address="192.168.5.7"/>
<saml:AuthnContext>
<saml:AuthnContextDeclRef>urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken</saml:AuthnContextDeclRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>
</samlp:Response>
For an additional comparison, here’s the AuthnRequest created by server B:
<?xml version="1.0" encoding="UTF-8"?><samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="http://b.example.com/Shibboleth.sso/SAML2/POST" Destination="https://idp.example.com/idp/profile/SAML2/Redirect/SSO" ID="_bf0e12a1672b3a0d5258edd394032e72" IssueInstant="2009-04-23T04:40:32Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">http://b.example.com/shibboleth-sp</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="1"/>
</samlp:AuthnRequest>
Well, I guess it helps to talk this out in an email asking for help, because now I’ve noticed one thing different about my relying-party.xml setup for A. I’ve got a typo difference in my entityID in the <RelyingParty> element. So, Shib would not be using the specific one and would instead use the <DefaultRelyingParty> element. I don’t see any difference in the setup though. The only thing I typically override is the encryptNameIds and encryptAssertions attributes to set them to never. The default setting is never also.
Ok, my brain is now officially fried. I’m sure I’ve done something stupid, so if someone sees my stupid mistake, I’ll buy them a beer the next time we meet.
Thanks,
Paul
Scott Cantor
handlers to use and which one gets selected. And in terms of code, tracing
that flow through the Authentication Manager code in the IdP I guess.
But in terms of messing with the relying party options, I think there's a
setting for the default authentication method/class used. Maybe that's
coming into play?
-- Scott
Paul Hethmon
> I suspect the log area to focus on is the evaluation of the possible login
> handlers to use and which one gets selected. And in terms of code, tracing
> that flow through the Authentication Manager code in the IdP I guess.
I'll check that. I really only have my one custom login handler defined plus
previous session.
>
> But in terms of messing with the relying party options, I think there's a
> setting for the default authentication method/class used. Maybe that's
> coming into play?
Could be. The default relying party doesn't specify a preference while my
specific relying party's do.
Getting ready to run the IdP locally, override the hostname, and really turn
up the debug.
Scott Cantor
> Could be. The default relying party doesn't specify a preference while my
> specific relying party's do.
The trick though is that if the one the default RP element specifies doesn't
match what's in the session, then it won't allow that session to be reused
without running a login handler that can contribute that additional
method/class to the session.
I think. Obviously Chad's the authority, but that's what I believe was
intended from the design.
-- Scott
Paul Hethmon
> Paul Hethmon wrote on 2009-04-23:
>> Could be. The default relying party doesn't specify a preference while my
>> specific relying party's do.
>
> The trick though is that if the one the default RP element specifies doesn't
> match what's in the session, then it won't allow that session to be reused
> without running a login handler that can contribute that additional
> method/class to the session.
Bingo. That was it.
So to make sure I understand this correctly. In my specific <RelyingParty>
elements, I had the "defaultAuthenticationMethod" attribute specified.
Specifically to PasswordProtectedTransport. The <DefaultRelyingParty>
element did not specify that attribute and probably defaulted to another
value. So the IdP would not let the one session to be used for the Previous
Session handler in that case since the requirements were different.
It makes sense now, just didn't realize the ability and flexibility there.
Thanks,
Chad La Joie
"Authentication Method Selection" which, oddly enough, talk about how
the authentication method is selected. The relying party configuration
documentation also notes that if define a <RelyingParty> NO settings are
inherited from the <DefaultRelyingPaty>.
[1] https://spaces.internet2.edu/display/SHIB2/IdPUserAuthn
--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad....@switch.ch, http://www.switch.ch
Scott Cantor
> So to make sure I understand this correctly. In my specific <RelyingParty>
> elements, I had the "defaultAuthenticationMethod" attribute specified.
> Specifically to PasswordProtectedTransport. The <DefaultRelyingParty>
> element did not specify that attribute and probably defaulted to another
> value. So the IdP would not let the one session to be used for the
Previous
> Session handler in that case since the requirements were different.
Well, absent a value I would think it ends up using the "unspecified" class,
and that should be handled somewhat differently for matching purposes. I
believe there's code that just clears the list of "requested" classes in
that case, meaning anything should be acceptable.
But I'm not really that familiar with it.
Of course, if the default is for something totally different than
"unspecified", that's a different story.
In general, I think people overuse the relying party overrides and get
themselves into trouble as a result. Other than setting up attribute push
and some SAML compatibility things for non-Shib SPs, I've never had to use
it in the old IdP.
-- Scott
Paul Hethmon
> Note that the authentication documentation[1] contains a section called
> "Authentication Method Selection" which, oddly enough, talk about how
> the authentication method is selected. The relying party configuration
> documentation also notes that if define a <RelyingParty> NO settings are
> inherited from the <DefaultRelyingPaty>.
>
> [1] https://spaces.internet2.edu/display/SHIB2/IdPUserAuthn
So I'm reading that page and this one:
https://spaces.internet2.edu/display/SHIB2/IdPAuthnSession
And while I see what I missed in there now, I didn't pick up on it before. I
think I need to go read some of the spec documents a bit closer now, but is
it correct to say that Shib does not have any hierarchy of authentication
methods? So, while it's generally accepted that two-factor is stronger
authentication than simple passwords (one-factor). If I had authenticated
via two-factor to SP1, but SP2 wants username/pwd, then Shib would ask me to
re-authenticate. Correct?
Paul Hethmon
> In general, I think people overuse the relying party overrides and get
> themselves into trouble as a result. Other than setting up attribute push
> and some SAML compatibility things for non-Shib SPs, I've never had to use
> it in the old IdP.
I'm with you on this one. I have it configured that way today, but the only
thing it has gotten me is extra complexity. Like mistyping an entityID value
and ending up where I was last night. I haven't actually had to use it to
change behavior.
Paul
Chad La Joie
than one-factor. It totally depends on the mechanisms and the practices
of people who use them. I could, for example, make a pretty strong case
that username/password is commonly STRONGER than client-cert auth.
--
Paul Hethmon
> That is correct. Note thogh that two-factor is not "generally" stronger
> than one-factor. It totally depends on the mechanisms and the practices
> of people who use them. I could, for example, make a pretty strong case
> that username/password is commonly STRONGER than client-cert auth.
Well, I won't bite on that argument, but I did update the wiki to help the
next guy.
Scott Cantor
> next guy.
Reading your change, that's the part I'm still confused by. I was fairly
certain that "unspecified" as an input to the selection process is not a
normal value, but a catch all that should match anything that happens to be
available.
I thought that's what Chad meant by "it selects a random handler".
What I thought might be going on with your case is that you had two handlers
with actual methods specified for them, and it was randomly picking the
other one. That's not specifically because it's picking one labeled with
"unspecified", but because "unspecified" means it can pick either one.
-- Scott
Chad La Joie
the "unspecified" URL or not sending anything means to look at the
default authn method. A lack of a specified method or specifying the
"unspecified" method means "unspecified".
--
Paul Hethmon
> Right. "unspecified" means randomly pick one. The SP sending either
> the "unspecified" URL or not sending anything means to look at the
> default authn method. A lack of a specified method or specifying the
> "unspecified" method means "unspecified".
To add to that. I'm sure Shib is passing "unspecified" into my login
handler, but my handler is not updating the method used. So, to Shib, the
"unspecified" remains "unspecified" in the session. In the other RP case,
Shib sends in "UsernamePassword" since that was specified in the config and
again I leave it alone on the outbound.
So, I could have my login handler update the method used to reflect a real
method instead of "unspecified" and I would not have seen the problem.
I'm actually working on a handler that will do that, but for the purpose of
distinguishing whether a user used a fixed password or OTP token to
authenticate so the RP knows.
Scott Cantor
> method instead of "unspecified" and I would not have seen the problem.
Ok, that explains my confusion. Thanks.
-- Scott
Paul Hethmon
>> So, I could have my login handler update the method used to reflect a real
>> method instead of "unspecified" and I would not have seen the problem.
>
> Ok, that explains my confusion. Thanks.
NP. I also added a note to that effect on the wiki since it really depends
on both configuration and the login handler in use.
I think I still owe you a beer.
John Nowlin
I am attempting to use the SampleLoginModule provided by SUN in their JAAS Authorization Tutorial in the IdP. So I modified handler.xml and login.config in an attempt to point to this module.
Handler.xml
<!-- Username/password login handler -->
<LoginHandler xsi:type="UsernamePassword"
jaasConfigurationLocation="file://C:\opt\shibboleth-idp-21/conf/login.config">
<AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthenticationMethod>
</LoginHandler>
Login.config
ShibUserPassAuth {
authnsamples.SampleLoginModule required debug=true;
I can see in the idp-process.log where the login.config is loaded.
14:44:15.620 - DEBUG [edu.internet2.middleware.shibboleth.idp.config.profile.ProfileHandlerGroupBeanDefinitionParser:57] - 2 login handler definitions found
14:44:15.620 - DEBUG [edu.internet2.middleware.shibboleth.idp.config.profile.authn.AbstractLoginHandlerBeanDefinitionParser:42] - Parsing configuration for UsernamePassword authentication handler.
14:44:15.620 - DEBUG [edu.internet2.middleware.shibboleth.idp.config.profile.authn.AbstractLoginHandlerBeanDefinitionParser:48] - Authentication handler declared duration of 30 minutes
14:44:15.620 - DEBUG [edu.internet2.middleware.shibboleth.idp.config.profile.authn.AbstractLoginHandlerBeanDefinitionParser:57] - Authentication handler declared support for authentication method urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
14:44:15.620 - DEBUG [edu.internet2.middleware.shibboleth.idp.config.profile.authn.UsernamePasswordLoginHandlerBeanDefinitionParser:57] - Setting JAAS configuration file to: file://C:\opt\shibboleth-idp-21/conf/login.config
I have tried all manner of directory and domain name paths for the SampleLoginModule yet always get an Authentication Failed from login.jsp.
14:49:10.995 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:163] - Attempting to authenticate user testUser
14:49:11.011 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:192] - User authentication for [testUser] failed
14:49:11.073 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:142] - Redirecting to login page /login.jsp
I can’t find any information in the logs to decide where the authentication failure is occurring. Which log should I check to see if the SampleLoginModule is actually being loaded or where the authentication is actually failing?
Sincerely
john
John Nowlin
College Center for Library Automation
Paul Hethmon
I am attempting to use the SampleLoginModule provided by SUN in their JAAS Authorization Tutorial in the IdP. So I modified handler.xml and login.config in an attempt to point to this module.
Does the web.xml point to the correct module? The standard servlet will attempt to load a JAAS compliant module that you specify there.
John Nowlin
Thank you for pointing a shibboleth beginner along the way. Which web.xml should I be modifying?
Here are all the ones in my tomcat directories, none of which live in the idp directory tree.
dir/s/b web.xml
C:\Program Files\Apache Software Foundation\Tomcat 6.0\conf\web.xml
C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\docs\appdev\sample\web\WEB-INF\web.xml
C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\docs\WEB-INF\web.xml
C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\host-manager\WEB-INF\web.xml
C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\manager\WEB-INF\web.xml
C:\Program Files\Apache Software Foundation\Tomcat 6.0\webapps\ROOT\WEB-INF\web.xml
dir /s/b idp
C:\Program Files\Apache Software Foundation\Tomcat 6.0\work\Catalina\localhost\idp
John Nowlin
Paul Hethmon
I am attempting to use the SampleLoginModule provided by SUN in their JAAS Authorization Tutorial in the IdP. So I modified handler.xml and login.config in an attempt to point to this module.
Does the web.xml point to the correct module? The standard servlet will attempt to load a JAAS compliant module that you specify there.
I think I pointed you a bit in the wrong direction. I actually override the servlet for my needs since JAAS didn’t offer enough flexibility for my needs. So handler.xml and login.config are the correct places to put a compliant JAAS module configuration. Beyond that, make sure your JAR file is available to the IdP, plus any other required jars. When you first attempted this, did you see any errors in the IdP or Tomcat logs? Maybe a missing dependency?
Paul
-----
Paul Hethmon
Chief Software Architect
Clareity Security, LLC
865.824.1350 - office
865.250.3517 - mobile
www.clareitysecurity.com
-----
-- Terry Pratchett, Good Omens
John Nowlin
I see nothing in the log files, although after examining the UsernamePasswordLoginServlet.java file I see why. The entire section that uses the JAAS is in a try/catch so that there is no error message to find, as any screw-up I create in the JAAS file is caught and noted as a login failure.
try {
log.debug("Attempting to authenticate user {}", username);
SimpleCallbackHandler cbh = new SimpleCallbackHandler(username, password);
javax.security.auth.login.LoginContext jaasLoginCtx = new javax.security.auth.login.LoginContext(
jaasConfigName, cbh);
jaasLoginCtx.login();
log.debug("Successfully authenticated user {}", username);
Subject loginSubject = jaasLoginCtx.getSubject();
Set<Principal> principals = loginSubject.getPrincipals();
if (principals.isEmpty()) {
principals.add(new UsernamePrincipal(username));
}
Set<Object> publicCredentials = loginSubject.getPublicCredentials();
Set<Object> privateCredentials = loginSubject.getPrivateCredentials();
if (storeCredentialsInSubject) {
privateCredentials.add(new UsernamePasswordCredential(username, password));
}
Subject userSubject = new Subject(false, principals, publicCredentials, privateCredentials);
request.setAttribute(LoginHandler.SUBJECT_KEY, userSubject);
return true;
} catch (Throwable e) {
log.debug("User authentication for {} failed", new Object[] {username}, e);
return false;
}
Since I am inexperienced at java maybe somebody can guide me. Suppose I put the ShibUserPassAuth.jar file I created in the c:\opt\ directory on my machine near all the other shibboleth files. What would I put in the login.config file to direct the JAAS to find that jar file? If that is not the place to put the jar file, where would be a better place. I assure you I have tried many different combinations of locations and login.config variations.
Determinedly
john
From: Paul Hethmon
[mailto:paul.h...@clareitysecurity.com]
Sent: Monday, April 27, 2009 11:43 AM
To: Shibboleth Users
Subject: Re: [Shib-Users] JAAS configuration log file?
On 4/27/09 11:26 AM, "John Nowlin" <JNo...@cclaflorida.org> wrote:
Scott Cantor
> Since I am inexperienced at java maybe somebody can guide me. Suppose I
> put the ShibUserPassAuth.jar file I created in the c:\opt\ directory on
> my machine near all the other shibboleth files.
No, you want to put it in the lib folder in the source distribution and then
re-run the install script so it gets into the warfile.
> What would I put in the
> login.config file to direct the JAAS to find that jar file?
You don't reference the jar, you reference the class name of the LoginModule
from that file.
-- Scott