Which handler LDAP SSO - NOW kerberos integration
Douglas E Engert
deengert at gmail.com
Wed Nov 19 08:37:29 EST 2014
On 11/19/2014 6:28 AM, Morris, Andi wrote:
> Hi and thanks Douglas.
>
> I put that patch in and something is now broken. The patch itself wasn't without errors:
>
> -----------------------------------------------------------------------------------------------------------
> [root at shibidpdev01 webapp]# patch kerberos-login.inc.jsp < java-k.diff
The patch command above does not look correct. The patch patches 3 files,
and should start at the top of the handler source (You may want to make a backup
copy first and look something like:
patch -p0 < java-k.diff
To test the patch process, try
patch --dry-run -p0 < java-k.diff
> (Stripping trailing CRs from patch.)
> patching file kerberos-login.inc.jsp
> Hunk #1 FAILED at 13.
> Hunk #2 FAILED at 73.
> Hunk #3 FAILED at 111.
> 3 out of 3 hunks FAILED -- saving rejects to file kerberos-login.inc.jsp.rej
These were for the pom.xml files to allow for using newer version of maven.
> (Stripping trailing CRs from patch.)
> patching file kerberos-login.inc.jsp
It looks like it patched kerberos-login.inc.jsp
> (Stripping trailing CRs from patch.)
> patching file kerberos-login.inc.jsp
> Hunk #1 FAILED at 145.
> 1 out of 1 hunk FAILED -- saving rejects to file kerberos-login.inc.jsp.rej
This was for
./src/main/java/ch/SWITCH/aai/idp/kerberos/KrbLoginServlet.java not kerberos-login.inc.jsp
So after applying the patch you have to rebuild the jar.
I am retired, and don't have access everything I used to, so you may have to make additional changes.
As I said in an earlier e-mail, this was used in a combined login.jsp, that let the user
select the type of login the wanted, and the patch would allow for a fallback in case autologin
was attempted first.
> ------------------------------------------------------------------------------------------------------------------------------------
> I'm now getting the following in process.log
> --------------------------------------------------------------------------------------------------------------------------------------
> 12:11:43.206 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginHandlerBeanDefinitionParser:51] - Parsing configuration for KERBEROS authentication handler.
> 12:11:43.207 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginHandlerBeanDefinitionParser:124] - domain = INTERNAL.UWIC.AC.UK
> 12:11:43.207 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginHandlerBeanDefinitionParser:135] - principal = HTTP/idp.dev.cardiffmet.ac.uk at INTERNAL.UWIC.AC.UK
> 12:11:43.207 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginHandlerBeanDefinitionParser:143] - keytab = /etc/shibdevkerb.keytab
> 12:11:43.208 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginHandlerBeanDefinitionParser:160] - Added realm for 'INTERNAL.UWIC.AC.UK'.
> 12:11:43.208 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginHandlerBeanDefinitionParser:100] - parsing configuration complete
> 12:11:43.469 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginHandlerFactoryBean:40] - creating KrbLoginHandler
> 12:11:43.470 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginHandler:183] - setSupportsPassive = false
> 12:11:43.474 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginHandler:185] - setSupportsForceAuthentication = false
> 12:11:43.474 - DEBUG [ch.SWITCH.aai.idp.kerberos.KrbLoginHandler:63] - system setProperty 'java.security.krb5.conf' = /etc/krb5.conf
> 12:11:43.474 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginHandlerFactoryBean:46] - kerberosCfg = /etc/krb5.conf
> 12:11:43.475 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginHandlerFactoryBean:55] - loginUrlPattern = null
> 12:11:43.475 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginHandlerFactoryBean:70] - krbServletPattern = /Authn/Kerberos/Login
> 12:11:43.475 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginHandlerFactoryBean:75] - autoLoginDurantion = 31536000 (seconds)
> 12:11:43.475 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginHandlerFactoryBean:80] - CustomUnauthorized = null
> 12:11:43.476 - INFO [edu.internet2.middleware.shibboleth.common.config.BaseService:180] - shibboleth.HandlerManager service loaded new configuration
> 12:12:43.202 - INFO [Shibboleth-Access:73] - 20141119T121243Z|192.168.42.42|idp.dev.cardiffmet.ac.uk:443|/profile/Metadata/SAML|
> 12:12:54.267 - INFO [Shibboleth-Access:73] - 20141119T121254Z|192.168.42.42|idp.dev.cardiffmet.ac.uk:443|/profile/SAML2/Redirect/SSO|
> 12:12:54.312 - DEBUG [ch.SWITCH.aai.idp.kerberos.KrbLoginHandler:297] - AutoLogin not active: redirecting to login page
> 12:12:54.312 - DEBUG [ch.SWITCH.aai.idp.kerberos.KrbLoginHandler:262] - Redirecting to login page
> 12:12:54.313 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginHandler:218] - Redirecting to /login.jsp
> 12:12:55.496 - ERROR [ch.SWITCH.aai.idp.kerberos.KrbLoginHandler:223] - Unable to redirect.
> org.apache.jasper.JasperException: Unable to compile class for JSP:
>
> An error occurred at line: 58 in the jsp file: /kerberos-login.inc.jsp
> autologin cannot be resolved
> 55: </div>
> 56: <%
> 57: if ("true".equals(request.getAttribute("krbLoginFailed"))) {
> 58: autologin = false;
> 59: }
> 60: %>
> 61: <%
Most likely caused by the jar not being rebuilt, and this line is still in the jar:
flushResponse(httpResponse, KrbLoginHandler.getCustomUnauthorizedCont());
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------
> It really feels that getting Kerberos integrated to Shibboleth is the most complex route possible, and I'm concerned with the future support of this should I ever get it up and running to be honest. I'm actually considering going back to the RemoteUser handler, with SSPI SSO, although we're also having issues with that in our production environment, namely that it doesn't like special characters being part of users password.
>
> Cheers to everyone for their help so far,
> Andi
>
>
> -----Original Message-----
> From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Douglas E Engert
> Sent: 18 November 2014 19:43
> To: users at shibboleth.net
> Subject: Re: Which handler LDAP SSO - NOW kerberos integration
>
>
>
> On 11/18/2014 10:39 AM, Morris, Andi wrote:
>> I'm so close with this now, thanks to you guys for your help so far.
>>
>> At the moment I have a username and password box appear when the with a button at the bottom when the user can click to send their Kerberos details. I'd like to automate this so that the Kerberos details are automatically used when the user accesses the page from a supported browser (IE). This is how we have this working in our prod environment with the remoteuser handler.
>>
>> My login page is login.jsp which was copied from login_example.jsp.
>>
>> I see the following in the log file:
>> DEBUG [ch.SWITCH.aai.idp.kerberos.KrbLoginHandler:297] - AutoLogin not
>> active: redirecting to login page
>>
>> However I can't see where in any of the Kerberos login config files that I can enable autologin.
>
> First of all the handling of failures in the kerberos login handler java code needs some changes.
> See attachment, that changes kerberos-login.inc.jsp and KrbLoginServlet.java.
>
> It has been awhile since I looked at this, but autoLogin is really only set by the user and saved in a cookie.
> The above change will turn it off if the kerberos fails, so the user can get a normal login page again.
>
> There were other changes to the login.jsp to allow the user to select of try want to try X509, or Kerberos.
> We added a kerberos-login-try-first.inc.jsp, modified the kerberos-login.inc.jsp and kerberos-default.jsp
>
> There was one SP we had, that we wanted to always use autologin, as on the terminal server the user would becoming from the user would have already logged on and have kerberos credentials. On the IDP we added a simple cgi script to set the cookie, and the URL was setup to run this and redirect to the SP.
>
>>
>> Another question is, do I need to reinstall the application each time
>> I make a change to anything within the shibinstall path folder? EG.,
>> /opt/shibboleth-identityprovider-2.4.3/src/main/webapp/login.jsp
>
> If you want the war file to have the changes.
>
>>
>> Cheers,
>> Andi
>>
>> -----Original Message-----
>> From: users-bounces at shibboleth.net
>> [mailto:users-bounces at shibboleth.net] On Behalf Of Morris, Andi
>> Sent: 13 November 2014 16:03
>> To: 'Shib Users'
>> Subject: RE: Which handler LDAP SSO - NOW kerberos integration
>>
>> Looking at the mailing list archives it appears I might need to wait for testshib to clear out my old metadata as I don't think I uploaded them with different filenames.
>>
>> I'll likely look to install my own dev SP anyway that I can use in the future which will of course resolve that.
>>
>> Cheers,
>> Andi
>> -----Original Message-----
>> From: users-bounces at shibboleth.net
>> [mailto:users-bounces at shibboleth.net] On Behalf Of Douglas E Engert
>> Sent: 13 November 2014 15:37
>> To: users at shibboleth.net
>> Subject: Re: Which handler LDAP SSO - NOW kerberos integration
>>
>> You have gotten by the Kerberos part, this looks like a metadata problem, maybe someone else can look at it.
>>
>>
>> On 11/13/2014 9:12 AM, Morris, Andi wrote:
>>> Thanks for that Douglas, I'll be sure to add that in once I have this all working.
>>>
>>> I'm now seeing more progress, but still issues.
>>>
>>> On sp.testshib.org I get:
>>> opensaml::FatalProfileException at
>>> (https://sp.testshib.org/Shibboleth.sso/SAML2/POST)
>>>
>>> Message was signed, but signature could not be verified.
>>>
>>> I know this points to the certificate not matching, but I've checked the SP logs and it is the same signature that is in my relying party.
>>>
>>> 2014-11-13 09:58:33 DEBUG OpenSAML.MessageDecoder.SAML2 [3513]:
>>> extracting issuer from SAML 2.0 protocol message
>>> 2014-11-13 09:58:33 DEBUG OpenSAML.MessageDecoder.SAML2 [3513]:
>>> message from (https://idp.dev.cardiffmet.ac.uk/idp/shibboleth)
>>> 2014-11-13 09:58:33 DEBUG OpenSAML.MessageDecoder.SAML2 [3513]: searching metadata for message issuer...
>>> 2014-11-13 09:58:33 DEBUG OpenSAML.SecurityPolicyRule.MessageFlow
>>> [3513]: evaluating message flow policy (replay checking on,
>>> expiration
>>> 60)
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.StorageService [3513]: inserted
>>> record (_4b2993720c9bd10984839670e7088021) in context (MessageFlow)
>>> with expiration (1415890953)
>>> 2014-11-13 09:58:33 DEBUG Shibboleth.SSO.SAML2 [3513]: processing
>>> message against SAML 2.0 SSO profile
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.KeyInfoResolver.Inline [3513]:
>>> resolved 0 certificate(s)
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.CredentialCriteria [3513]: key
>>> algorithm didn't match ('AES' != 'RSA')
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.CredentialCriteria [3513]: key
>>> algorithm didn't match ('AES' != 'RSA')
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.CredentialCriteria [3513]: key
>>> algorithm didn't match ('AES' != 'RSA')
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.KeyInfoResolver.Inline [3513]:
>>> resolving ds:X509Certificate
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.KeyInfoResolver.Inline [3513]:
>>> resolved 1 certificate(s)
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.CredentialCriteria [3513]:
>>> credential name(s) didn't overlap
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.CredentialCriteria [3513]: keys
>>> didn't match
>>> 2014-11-13 09:58:33 DEBUG Shibboleth.SSO.SAML2 [3513]: decrypted
>>> Assertion: <saml2:Assertion
>>> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
>>> ID="_2f0d0ae45f56954adb58fdb2bff814de"
>>> IssueInstant="2014-11-13T14:58:33.118Z" Version="2.0"><saml2:Issuer
>>> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idp.
>>> dev.cardiffmet.ac.uk/idp/shibboleth</saml2:Issuer><ds:Signature
>>> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:Cano
>>> n
>>> icalizationMethod
>>> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMet
>>> h
>>> od
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><ds:Reference
>>> URI="#_2f0d0ae45f56954adb58fdb2bff814de"><ds:Transforms><ds:Transform
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><d
>>> s
>>> :Transform
>>> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms>
>>> <
>>> ds:DigestMethod
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>L
>>> u HUxMP8d27OrPqkuuO8tB3HRlQ=</ds:DigestValue></ds:Reference></ds:S
>> ig
>>>
>>> nedInfo><ds:SignatureValue>Ft6nGEa4dmrqL085w4KU2g3h5rdWv6eN25VE6C7Wbz
>>> nedInfo>G
>>> XBNSCqxpFOcQBWh3YVjuz12ERBEiqh+jumqph6cuJSxFBehovZ23Tax24tg4P9/+KsMEs
>>> XBNSCqxpFOcQBWh3YVjuz12ERBEiqh+R
>>> f50w9O9HTPAtYOQD9yP7VKuJ48UNEWeOc7A8r9eb68rzLtS11cf20YCrGONuIl5TzmQrJ
>>> 3
>>> h+cvbvEfCvUOXEzsbdlxSNb273uKhwk6m7OASjeq8Z/1AagVhHhb+w+mFbKtvqCtsa1FT
>>> h+l
>>> V7tVfzebPLft1DBCb9eg2ebSDnSVviyKJIFNE4PF2v76B1WemgVxwU/U2mEmwPIP6q+zF
>>> e
>>> CoOzl/NHzxOaP6o4mdw==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:
>>> X509Certificate>MIIDTDCCAjSgAwIBAgIVAN88L4R+0kz0wXSzNKse0EpMQso3MA0GC
>>> X509Certificate>MIIDTDCCAjSgAwIBAgIVAN88L4R+S
>>> qGSIb3DQEBBQUAMCMxITAf
>>> BgNVBAMMGGlkcC5kZXYuY2FyZGlmZm1ldC5hYy51azAeFw0xNDExMTIxMzEzMzhaFw0zN
>>> D
>>> ExMTIx
>>> MzEzMzhaMCMxITAfBgNVBAMMGGlkcC5kZXYuY2FyZGlmZm1ldC5hYy51azCCASIwDQYJK
>>> o
>>> ZIhvcN
>>> AQEBBQADggEPADCCAQoCggEBAKVu2OQ1YaOL42l15dANGivbm2fno6XCIGz0DQVyXpsPd
>>> m
>>> b7LYpi
>>> gBlZH3MoQzEbcN1TmL6YAKekEGJ8ruH+NkqZ6l+vyqSA1lnWjMeOfJ3AYcQMm1S7QmSC6
>>> gBlZH3MoQzEbcN1TmL6YAKekEGJ8ruH+NkqZ6l+x
>>> gBlZH3MoQzEbcN1TmL6YAKekEGJ8ruH+NkqZ6l+yuD3lo
>>> 5mHgqmHj91hHH0tuHmZLZJzGef2CT/fOI164OanBwYxyaiNYzxMuX9ew2Eer0m8y6YYBB
>>> y
>>> vFTYuy
>>> LBQKAE87lUqUYJQ+LUUhTNp6Ap2ZEdPH8ZFKoG7L+F3ty9Woyn7nyfYitxkCRKtsacaiJ
>>> LBQKAE87lUqUYJQ+LUUhTNp6Ap2ZEdPH8ZFKoG7L+h
>>> LBQKAE87lUqUYJQ+LUUhTNp6Ap2ZEdPH8ZFKoG7L+9Nz34O
>>> Oe3nXVAnm2XqxFOE4K53XrW8Mwixbw7utuOhz4FPXXxisay1/swbNO/v7pj05KECAwEAA
>>> a
>>> N3MHUw
>>> HQYDVR0OBBYEFAlK7mnvW1R58aIsvQMNLjChoiP/MFQGA1UdEQRNMEuCGGlkcC5kZXYuY
>>> 2
>>> FyZGlm
>>> Zm1ldC5hYy51a4YvaHR0cHM6Ly9pZHAuZGV2LmNhcmRpZmZtZXQuYWMudWsvaWRwL3Noa
>>> W
>>> Jib2xl
>>> dGgwDQYJKoZIhvcNAQEFBQADggEBAJ8faMAT8CUPzHakBGGRfGMtVyWn5Qj1BXwTxqsPh
>>> /
>>> a4RFtn
>>> zpWf+PfMRTAIvKFa6LpqU+A8ObZ2aIN93AqT6TniJmxcoagLeUm+VXD6KJMAtnugZWoz8
>>> zpWf+PfMRTAIvKFa6LpqU+A8ObZ2aIN93AqT6TniJmxcoagLeUm+W
>>> zpWf+PfMRTAIvKFa6LpqU+A8ObZ2aIN93AqT6TniJmxcoagLeUm+OpMzxo
>>> MN98WRIXYslgGkoKDYrW8zYnU7LS01dToneTfgRQZJ5Klnn5S45j1dZZI+Anl4/HUGgTh
>>> MN98WRIXYslgGkoKDYrW8zYnU7LS01dToneTfgRQZJ5Klnn5S45j1dZZI+z
>>> MN98WRIXYslgGkoKDYrW8zYnU7LS01dToneTfgRQZJ5Klnn5S45j1dZZI+N9vQJi
>>> mKB68eLdil6n1DMgP8z5A1cC9Ot28XRTI/kO7ykFtd6Q8yzjczBc7AZ3Ef382mX4Zzr7R
>>> Z
>>> E2BrzF
>>> 1pU/c/Dld8pLc1YUpUxcfOuABgdih3vFwNgmlyXEOd6JsyRVe4fkLYy3B+KdXm4Tch4=<
>>> /
>>> ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><saml2:S
>>> u
>>> bject><saml2:NameID
>>> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
>>> NameQualifier="https://idp.dev.cardiffmet.ac.uk/idp/shibboleth"
>>> SPNameQualifier="https://sp.testshib.org/shibboleth-sp">_ee6f1b4caffb
>>> 3 4e7ec9dd6196a48161c</saml2:NameID><saml2:SubjectConfirmation
>>> Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml2:SubjectConfirma
>>> t
>>> ionData Address="192.168.42.42"
>>> InResponseTo="_f5f27cf7d9cab13afa6b246b63f42bc2"
>>> NotOnOrAfter="2014-11-13T15:03:33.118Z"
>>> Recipient="https://sp.testshib.org/Shibboleth.sso/SAML2/POST"/></saml
>>> 2 :SubjectConfirmation></saml2:Subject><saml2:Conditions
>>> NotBefore="2014-11-13T14:58:33.118Z"
>>> NotOnOrAfter="2014-11-13T15:03:33.118Z"><saml2:AudienceRestriction><s
>>> a
>>> ml2:Audience>https://sp.testshib.org/shibboleth-sp</saml2:Audience></
>>> s aml2:AudienceRestriction></saml2:Conditions><saml2:AuthnStatement
>>> AuthnInstant=
>> "2
>>> 014-11-13T14:58:33.104Z"
>>> SessionIndex="_53201c5ff6945bde10cf00907c3e855e"><saml2:SubjectLocali
>>> t
>>> y
>>> Address="192.168.42.42"/><saml2:AuthnContext><saml2:AuthnContextClass
>>> R
>>> ef>urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos</saml2:AuthnContex
>>> ef>t
>>> ClassRef></saml2:AuthnContext></saml2:AuthnStatement></saml2:Assertio
>>> ClassRef>n
>>>>
>>> 2014-11-13 09:58:33 DEBUG Shibboleth.SSO.SAML2 [3513]: extracting
>>> issuer from SAML 2.0 assertion
>>> 2014-11-13 09:58:33 DEBUG OpenSAML.SecurityPolicyRule.MessageFlow
>>> [3513]: evaluating message flow policy (replay checking on,
>>> expiration
>>> 60)
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.StorageService [3513]: inserted
>>> record (_2f0d0ae45f56954adb58fdb2bff814de) in context (MessageFlow)
>>> with expiration (1415890953)
>>> 2014-11-13 09:58:33 DEBUG OpenSAML.SecurityPolicyRule.XMLSigning
>>> [3513]: validating signature profile
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.KeyInfoResolver.Inline [3513]:
>>> resolving ds:X509Certificate
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.KeyInfoResolver.Inline [3513]:
>>> resolved 1 certificate(s)
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.KeyInfoResolver.Inline [3513]:
>>> resolved 0 CRL(s)
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.CredentialCriteria [3513]: keys
>>> didn't match
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.ExplicitKey [3513]:
>>> unable to validate signature, no credentials available from peer
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.PKIX [3513]:
>>> validating signature using certificate from within the signature
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.PKIX [3513]: signature verified with key inside signature, attempting certificate validation...
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.PKIX [3513]:
>>> checking that the certificate name is acceptable
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.PKIX [3513]: adding
>>> to list of trusted names
>>> (https://idp.dev.cardiffmet.ac.uk/idp/shibboleth)
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.PKIX [3513]:
>>> certificate subject: CN=idp.dev.cardiffmet.ac.uk
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.PKIX [3513]: unable
>>> to match DN, trying TLS subjectAltName match
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.PKIX [3513]: matched
>>> DNS/URI subjectAltName to a key name
>>> (https://idp.dev.cardiffmet.ac.uk/idp/shibboleth)
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.PKIX [3513]: performing certificate path validation...
>>> 2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.PKIX [3513]: failed
>>> to validate certificate chain using supplied PKIX information
>>> 2014-11-13 09:58:33 ERROR OpenSAML.SecurityPolicyRule.XMLSigning
>>> [3513]: unable to verify message signature with supplied trust engine
>>> 2014-11-13 09:58:33 WARN Shibboleth.SSO.SAML2 [3513]: detected a problem with assertion: Message was signed, but signature could not be verified.
>>> 2014-11-13 09:59:25 INFO XMLTooling.StorageService : purged 2 expired
>>> record(s) from storage
>>>
>>> My IDP logs show:
>>>
>>> 14:58:23.219 - INFO [Shibboleth-Access:73] -
>>> 20141113T145823Z|192.168.42.42|idp.dev.cardiffmet.ac.uk:443|/profile/
>>> 20141113T145823Z|S
>>> AML2/Redirect/SSO|
>>> 14:58:23.230 - DEBUG [ch.SWITCH.aai.idp.kerberos.KrbLoginHandler:297]
>>> - AutoLogin not active: redirecting to login page
>>> 14:58:23.230 - DEBUG [ch.SWITCH.aai.idp.kerberos.KrbLoginHandler:262]
>>> - Redirecting to login page
>>> 14:58:23.230 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginHandler:218]
>>> - Redirecting to /login.jsp
>>> 14:58:23.232 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginHandler:105]
>>> - cookie '_idp_krb_autologin' created [value=false, maxage=31536000,
>>> path=/idp, secure=true, domain=null]
>>> 14:58:23.232 - INFO [ch.SWITCH.aai.idp.kerberos.KrbLoginHandler:249] - 'auto login' cookie sent.
>>> 14:58:28.053 - INFO [ch.SWITCH.aai.idp.kerberos.KrbLoginServlet:125]
>>> - kerberos idp servlet started
>>> 14:58:28.053 - DEBUG [ch.SWITCH.aai.idp.kerberos.HttpNegotiator:72] - HTTP: Returning response code '401'. Authorization header not found.
>>> 14:58:28.068 - INFO [ch.SWITCH.aai.idp.kerberos.KrbLoginServlet:125]
>>> - kerberos idp servlet started
>>> 14:58:28.069 - TRACE [ch.SWITCH.aai.idp.kerberos.HttpNegotiator:77] - HTTP: Authorization header found.
>>> 14:58:28.069 - DEBUG
>>> [ch.SWITCH.aai.idp.kerberos.KrbContextAcceptor:87] - Validating GSS
>>> token. Realm: INTERNAL.UWIC.AC.UK
>>> 14:58:28.069 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbContextAcceptor:118] - Logging KDC 'INTERNAL.UWIC.AC.UK'.
>>> 14:58:33.091 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbContextAcceptor:127] - KDC Logging successful.
>>> 14:58:33.091 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbContextAcceptor:133] - Creating GSS context.
>>> 14:58:33.093 - DEBUG [ch.SWITCH.aai.idp.kerberos.KrbContextAcceptor:145] - GSS context created.
>>> 14:58:33.094 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbContextAcceptor:150] - Validating the GSS Token.
>>> 14:58:33.101 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbContextAcceptor:92] - Security context established.
>>> 14:58:33.103 - DEBUG [ch.SWITCH.aai.idp.kerberos.HttpNegotiator:109] - Context established.
>>> 14:58:33.103 - DEBUG [ch.SWITCH.aai.idp.kerberos.HttpNegotiator:117]
>>> -
>>> Principal: username at INTERNAL.UWIC.AC.UK
>>> 14:58:33.103 - DEBUG [ch.SWITCH.aai.idp.kerberos.HttpNegotiator:124] - HTTP: Returning response code '200' and the gssapi data to complet the context.
>>> 14:58:33.103 - DEBUG [ch.SWITCH.aai.idp.kerberos.KrbLoginServlet:164]
>>> - Returning PRINCIPAL_NAME_KEY=username at INTERNAL.UWIC.AC.UK
>>> 14:58:33.103 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginServlet:177] - Setting request attribute 'authnMethod' to 'urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos'
>>> 14:58:33.103 - DEBUG [ch.SWITCH.aai.idp.kerberos.KrbLoginServlet:182]
>>> - Returning to Authentication Engine
>>> 14:58:33.116 - INFO [Shibboleth-Access:73] -
>>> 20141113T145833Z|192.168.42.42|idp.dev.cardiffmet.ac.uk:443|/profile/
>>> 20141113T145833Z|S
>>> AML2/Redirect/SSO|
>>> 14:58:33.138 - INFO [Shibboleth-Audit:1028] -
>>> 20141113T145833Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|_
>>> 20141113T145833Z|f
>>> 5f27cf7d9cab13afa6b246b63f42bc2|https://sp.testshib.org/shibboleth-sp
>>> 5f27cf7d9cab13afa6b246b63f42bc2||
>>> urn:mace:shibboleth:2.0:profiles:saml2:sso|https://idp.dev.cardiffmet.
>>> ac.uk/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_
>>> 4
>>> b2993720c9bd10984839670e7088021|username at INTERNAL.UWIC.AC.UK|urn:oasi
>>> b2993720c9bd10984839670e7088021|s
>>> :names:tc:SAML:2.0:ac:classes:Kerberos||_ee6f1b4caffb34e7ec9dd6196a48
>>> 1
>>> 61c||
>>>
>>> The wiki suggests that I'm either using the wrong certificates, or my idp is spoofing another one, but I really am not sure how that would have happened.
>>>
>>> Cheers,
>>> Andi
>>>
>>> -----Original Message-----
>>> From: users-bounces at shibboleth.net
>>> [mailto:users-bounces at shibboleth.net] On Behalf Of Douglas E Engert
>>> Sent: 13 November 2014 11:04
>>> To: users at shibboleth.net
>>> Subject: Re: Which handler LDAP SSO
>>>
>>>
>>>
>>> On 11/13/2014 2:47 AM, Morris, Andi wrote:
>>>> Cheers Douglas, that was helpful.
>>>>
>>>> I discovered that the keytab file was only readable by the apache user and not the tomcat user. I've chmod'd this so that only the tomcat user has access, and the Kerberos user is now authenticated.
>>>>
>>>>> With AD as ldap, you may want to add:
>>>>> (!(userAccountControl:1.2.840.113556.1.4.803:=2))
>>>>> to not accept disabled accounts.
>>>>
>>>> Really interested in that. How would I plumb that in?
>>>
>>> Your filter would look like:
>>>
>>>
>>> (&(|(mail=$requestContext.principalName)(&(samaccountname=${krb_princ
>>> i
>>> palname.get(0)})(msSFU30NisDomain=${krb_domain.get(0)})))(objectclass
>>> =
>>> user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
>>>
>>>>
>>>> Cheers,
>>>> Andi
>>>>
>>>> -----Original Message-----
>>>> From: users-bounces at shibboleth.net
>>>> [mailto:users-bounces at shibboleth.net] On Behalf Of Douglas E Engert
>>>> Sent: 12 November 2014 21:22
>>>> To: users at shibboleth.net
>>>> Subject: Re: Which handler LDAP SSO
>>>>
>>>>
>>>>
>>>> On 11/12/2014 8:08 AM, Morris, Andi wrote:
>>>>> Ok, thanks Peter.
>>>>> I'm getting somewhere with this, slowly and frustratingly so.
>>>>>
>>>>> I have Kerberos running between my idp box and my Active Directory servers, that was the easy bit.
>>>>>
>>>>> I've gone through https://crypt.ncl.ac.uk/login-gateway/docs/Shibboleth_SPNEGO_Setup.pdf up until the part where the login.jsp is modded to autodetect browsers, ip addresses and relying parties, as I don't think that's necessary for my site. I've also been cross referencing these against the documentation at https://wiki.shibboleth.net/confluence/display/SHIB2/Kerberos+Login+Handler which had some confusing parts, but I think I've made it through the majority. I wasn't sure with the section at the beginning of the handler.xml in the wiki as it doesn't describe whether to add these new schemas, replace the old ones, and amend them for the shibboleth setup. I ended up putting:
>>>>>
>>>>>
>>>>> <ph:ProfileHandlerGroup xmlns:ph="urn:mace:shibboleth:2.0:idp:profile-handler" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>> xmlns:krb="http://www.switch.ch/aai/idp/kerberos" krb:schemalocation="http://www.switch.ch/aai/idp/kerberos classpath:/schema/kerberos-login-handler.xsd"
>>>>>
>>>>> xsi:schemaLocation="urn:mace:shibboleth:2.0:idp:profile-handler
>>>>> classpath:/schema/shibboleth-2.0-idp-profile-handler.xsd">
>>>>>
>>>>> Is this correct?
>>>>
>>>> Before I retired, we used something like this, that added the krb5 and x509 handlers to the original user/password group Realm/AD dommain name changed to OURREALM.EDU. IDP on RedHat.
>>>>
>>>>
>>>> <ph:ProfileHandlerGroup xmlns:ph="urn:mace:shibboleth:2.0:idp:profile-handler"
>>>> xmlns:x509="http://www.switch.ch/aai/idp/x509"
>>>> xmlns:krb="http://www.switch.ch/aai/idp/kerberos"
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>
>>>> xsi:schemaLocation="urn:mace:shibboleth:2.0:idp:profile-handler
>>>> classpath:/schema/shibboleth-2.0-idp-profile-handler.xsd
>>>> http://www.switch.ch/aai/idp/x509
>>>> classpath:/schema/x509-login-handler.xsd
>>>> http://www.switch.ch/aai/idp/kerberos
>>>> classpath:/schema/kerberos-login-handler.xsd">
>>>>
>>>> The later in the group:
>>>> <!-- Kerberos Idp -->
>>>> <ph:LoginHandler xsi:type="krb:KERBEROS"
>>>> kerberosCfg="/etc/krb5.conf"
>>>> customUnauthorized="/opt/shibboleth-idp-2.3.8/other/unauthorized.html"
>>>> autoLoginDurantion="300"
>>>> loginPagePattern="/kerberos-login-try-first.jsp"
>>>> krbServletPattern="/Authn/Kerberos/Login"
>>>>
>>>> <!-- LoginHandler optional attributes:
>>>> kerberosCfg - kerberos configuration file
>>>> customUnauthorized - custom html page for error 401 - Unauthorized. (e.g.: jar:/example/unauthorized.html)
>>>> auto_login_durantion - auto login duration (seconds)
>>>> loginPagePattern - (default: "/login.jsp") - path for login page
>>>> krbServletPattern - (default: "/Authn/Kerberos") - path for kerberos login page
>>>> -->
>>>> <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos</ph:AuthenticationMethod>
>>>> <krb:Realm domain="OURREALM.EDU">
>>>> <krb:principal>HTTP/idp.ourrealm.edu at OURREALM.EDU</krb:principal>
>>>> <krb:keytab>/etc/krb5.keytab.http</krb:keytab>
>>>> </krb:Realm>
>>>> </ph:LoginHandler>
>>>>
>>>>
>>>>
>>>>>
>>>>> However the main part I'm getting stuck on is the configuration of the attribute resolver. When restarting tomcat I get the following in the idp-process.log:
>>>>> 13:56:17.734 - INFO
>>>>> [edu.internet2.middleware.shibboleth.common.config.BaseService:158]
>>>>> - Loading new configuration for service
>>>>> shibboleth.AttributeResolver
>>>>> 13:56:17.790 - ERROR [edu.internet2.middleware.shibboleth.common.config.BaseService:188] - Configuration was not loaded for shibboleth.AttributeResolver service, error creating components. The root cause of this error was: org.xml.sax.SAXParseException: Key 'DataConnectorAttributeDefinitionDependencyRef' with value 'HTTP/servername.cardiffmet.ac.uk' not found for identity constraint of element 'AttributeResolver'.
>>>>>
>>>>> Now clearly it doesn't like the prinicipal name here. attribute-resolver.conf has the following configuration for that part, as taken from https://wiki.shibboleth.net/confluence/display/SHIB2/Kerberos+Login+Handler+-+Attribute+resolver:
>>>>> <resolver:DataConnector id="fhnwAdmLDAP"
>>>>> xsi:type="dc:LDAPDirectory"
>>>>> ldapURL="${ldap.address}"
>>>>> baseDN="OU=UserAccs,DC=internal,DC=domain,DC=ac,DC=uk"
>>>>> principal="${ldap.principal}"
>>>>> principalCredential="${ldap.credential}" >
>>>>
>>>> As noted in other responses, these do not look correct.
>>>>
>>>>> <resolver:Dependency ref="HTTP/servername.cardiffmet.ac.uk" />
>>>>> <resolver:Dependency ref="INTERNAL.DOMAIN.AC.UK" />
>>>>> <dc:FilterTemplate>
>>>>> <!--
>>>>> (mail=$requestContext.principalName) - matches UsernamePassword
>>>>> Principal
>>>>> &(samaccountname=${})(msSFU30NisDomain=${}) - matches Kerberos
>>>>> Principal
>>>>
>>>> Not the way we did it, but could be OK.
>>>>
>>>> With AD as ldap, you may want to add:
>>>> (!(userAccountControl:1.2.840.113556.1.4.803:=2))
>>>> to not accept disabled accounts.
>>>>
>>>> http://support.microsoft.com/kb/269181
>>>>
>>>>
>>>>> -->
>>>>> <![CDATA[
>>>>> (&(|(mail=$requestContext.principalName)(&(samaccountname=${krb_principalname.get(0)})(msSFU30NisDomain=${krb_domain.get(0)})))(objectclass=user))
>>>>> ]]>
>>>>> </dc:FilterTemplate>
>>>>> <dc:LDAPProperty name="java.naming.referral" value="follow"/>
>>>>> </resolver:DataConnector>
>>>>>
>>>>> What have I missed here.
>>>>
>>>> It is also not clear if your IDP is in the same DNS domain as the AD domain that your users are in.
>>>> This can make it harder for a client to determine if it needs to do cross realm.
>>>>
>>>> HTTP/servername.cardiffmet.ac.uk implies IDP is
>>>> servername.cardiffmet.ac.uk
>>>>
>>>> You say this is the realm name, INTERNAL.DOMAIN.AC.UK which implies AD domain name is internal.domain.ac.uk.
>>>>
>>>>
>>>>>
>>>>> Thanks in advance for any help,
>>>>> Andi
>>>>>
>>>>> -----Original Message-----
>>>>> From: users-bounces at shibboleth.net
>>>>> [mailto:users-bounces at shibboleth.net] On Behalf Of Peter Schober
>>>>> Sent: 11 November 2014 13:03
>>>>> To: users at shibboleth.net
>>>>> Subject: Re: Which handler LDAP SSO
>>>>>
>>>>> * Morris, Andi <amorris at cardiffmet.ac.uk> [2014-11-11 13:44]:
>>>>>> Thanks. I have UsernamePassword configured at the moment and I'm
>>>>>> having trouble getting the bind to work so that users can login,
>>>>>> but I'll continue to work on that.
>>>>>
>>>>> This is all within the JAAS config file, login.config, as per the Shib documentation.
>>>>>
>>>>>> However, when running against test shib I'm being shown a login
>>>>>> screen, as expected at the moment.
>>>>>
>>>>> Yes,
>>>>> https://wiki.shibboleth.net/confluence/display/SHIB2/IdPUserAuthn
>>>>> says
>>>>>
>>>>> "Username/Password:
>>>>> Presents the user with an authentication page and then checks the
>>>>> entered username and password against an LDAP directory or Kerberos 5
>>>>> domain."
>>>>>
>>>>> So the UsernamePassword will generate HTML to collect credentials, and validate them via LDAP (or Kerberos, but that doesn't change the fact that a HTML form is rendered at the IDP).
>>>>>
>>>>>
>>>>>> When I have the ldap running correctly will the users still be
>>>>>> shown this screen if they already currently have valid windows
>>>>>> credentials
>>>>>
>>>>> Yes.
>>>>>
>>>>>> or will I need to configure this with Kerberos? What we have at
>>>>>> the moment is users being logged on without being prompted when
>>>>>> they access a shibboleth resource internally.
>>>>>
>>>>> You'll have to do something entirely different:
>>>>>
>>>>> https://wiki.shibboleth.net/confluence/display/SHIB2/Kerberos+Login
>>>>> +
>>>>> H
>>>>> a
>>>>> ndler
>>>>>
>>>>> The folks from Uni Newcastle have quite complete documentation for this, IIRC, if you (or your peers from the UKfederation) don't find anything better to offer try this:
>>>>> https://www.google.com/search?q=newcastle+shib+SPNEGO
>>>>> -peter
>>>>> --
>>>>> To unsubscribe from this list send an email to
>>>>> users-unsubscribe at shibboleth.net
>>>>>
>>>>
>>>
>>
>
--
Douglas E. Engert <DEEngert at gmail.com>
More information about the users
mailing list