By: Markus Thielen user 16 Sep 2016 at 11:43 a.m. CDT

23 Responses
Markus Thielen gravatar
Hi there again, So now I have set up a more complex scenario. Wasnt easy to find everything. But it's kind of working: SP => IDP/Asimba (Gluu Server 1) => IDP (Gluu Server 2) After I found out all the necessary settings I finally receive a valid SAML response in my SP app after login. But it doesnt contain any attributes that make sense: ``` <saml2p:Response Destination="http://<sp-url>/saml/login_check" ID="_JeFDHkh__xnCtqv_DEDT-w" InResponseTo="_6e91371a4396e5ba6bde09574ebc77c64113771172" IssueInstant="2016-09-16T16:13:57.520Z" Version="2.0" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://<gluu1-url>/asimba/profiles/saml2</saml2:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#_JeFDHkh__xnCtqv_DEDT-w"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <ec:InclusiveNamespaces PrefixList="xs" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>DMLgIimGrDzVM8w5P7g93y+8yc8=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>FMlqJY6cjzQ7/aTZjeh2NEh5TKCqV/hOxpY7Ug+Xs5uoOkeUkKnRczJi9YWglsbpdvlHzSdiDSuEPY+zfgYvor2am0PsPf9uHH1OH4Q9jGTkt25GUKCTJwVzoKXaL+Ll+vg/XX5usRWhQhfs3Widtl27LYYTBhwpuVwN38dwdqc3JiOZ3zKkaqMbJtnyDZsk5HIyTnjLQ3ohlbOZhW90ctzHsJ7ZFhE5UHK5No/RCfNMDm4Of6Cr1FD9/5R7xW8xkXmzIwOIRlWa3Rx2ZcKiiBLsLkfGUBZMsOvFudOVsfo5aXvzqzqIwr/lcEWQFojMGCoQ4ZEnJTfMGhtETLnAFw==</ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>...</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </ds:Signature> <saml2p:Status> <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> </saml2p:Status> <saml2:Assertion ID="_qcAkMzGMz1PI5iPynRwZGpOAMdAspxNsg8iaAcyqZkf-zJhKHEnK1tTulcXOy4_Sht_UT5yc0S-jXh0jmG9h9FTRsV4e-axT1V-ISlo8VNOY3mXoAZrhcIFWPeslrhSiNqN4O_L9Kyo1y775-a9LB1iBJh-ysetwIdL1bRwiWAG07HrIlD85G7RDqFntb2gZIAozpZjnWo6ibDgAyzHtiSAmfVW01ld9JI-NP5fb3glj-aVGeMhsoZWBZdVBvjk0lLe5TzdvfIHV00NAXu_5CuRSgSlqC5-iuUpG7Yd1OwLs7nPNx__X9ShsKQ1FSoC_oNRrwAGeVxVJIcfnfbXYUQ" IssueInstant="2016-09-16T16:13:57.520Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> <saml2:Issuer>https://<gluu1-url>/asimba/profiles/saml2</saml2:Issuer> <saml2:Subject> <saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="https://<gluu1-url>/asimba/profiles/saml2">_1063621954c71bb6a965c83fceb5ef2d!http://<sp-url></saml2:NameID> <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml2:SubjectConfirmationData InResponseTo="_6e91371a4396e5ba6bde09574ebc77c64113771172" NotOnOrAfter="2016-09-16T16:15:57.520Z" Recipient="http://<sp-url>/saml/login_check"/> </saml2:SubjectConfirmation> </saml2:Subject> <saml2:Conditions NotBefore="2016-09-16T16:13:57.520Z" NotOnOrAfter="2016-09-16T16:15:57.520Z"> <saml2:AudienceRestriction> <saml2:Audience>http://<sp-url></saml2:Audience> </saml2:AudienceRestriction> </saml2:Conditions> <saml2:AuthnStatement AuthnInstant="2016-09-16T16:13:57.520Z" SessionIndex="_qcAkMzGMz1PI5iPynRwZGpOAMdAspxNsg8iaAcyqZkf-zJhKHEnK1tTulcXOy4_Sht_UT5yc0S-jXh0jmG9h9FTRsV4e-axT1V-ISlo8VNOY3mXoAZrhcIFWPeslrhSiNqN4O_L9Kyo1y775-a9LB1iBJh-ysetwIdL1bRwiWAG07HrIlD85G7RDqFntb2gZIAozpZjnWo6ibDgAyzHtiSAmfVW01ld9JI-NP5fb3glj-aVGeMhsoZWBZdVBvjk0lLe5TzdvfIHV00NAXu_5CuRSgSlqC5-iuUpG7Yd1OwLs7nPNx__X9ShsKQ1FSoC_oNRrwAGeVxVJIcfnfbXYUQ" SessionNotOnOrAfter="2016-09-16T17:13:57.471Z"> <saml2:AuthnContext> <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef> <saml2:AuthenticatingAuthority>https://<gluu2-url>/idp/shibboleth</saml2:AuthenticatingAuthority> </saml2:AuthnContext> </saml2:AuthnStatement> <saml2:AttributeStatement> <saml2:Attribute Name="country" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Netherlands</saml2:AttributeValue> </saml2:Attribute> </saml2:AttributeStatement> </saml2:Assertion> </saml2p:Response> ``` There is only AttributeStatement: - country=Netherlands I have no idea where this is coming from. I didnt set up any country field anywhere. Also the NameID (_1063621954c71bb6a965c83fceb5ef2d!http://<sp-url>) is something I dont understand what it is. Could you please give me a hint? Thank you very much & kind regards Markus

By Michael Schwartz Account Admin 16 Sep 2016 at 12:47 p.m. CDT

Michael Schwartz gravatar
I better diagram (or even better, a sequence diagram), would help us really understand what you are trying to do. One thing that stands out is that you are pointing an SP at the Asimba IDP interface? This is not really what we designed. Normally an SP would point at the Shibboleth IDP interface, the default authn mechanism is set to "SAML", and the SP in this case is the oxAuth interception script. You can checkout this [working document](https://ox.gluu.org/doku.php?id=asimba:setup_testing) But again, it's really hard to say if this is right because your requirements are so fuzzy.

By Markus Thielen user 17 Sep 2016 at 2:39 a.m. CDT

Markus Thielen gravatar
Hi Mike, Thank you, that clears up a lot!! My scenario is just like the one in the wiki document. Thanks for the link. I changed everything and followed the wiki line by line. Now I got stuck by the asimba saml certificate used by the interception script. The wiki says: > asimba_saml_certificate_file: /etc/certs/saml.pem [ SAML certificate of asimba server ] I dont have a /etc/certs/saml.pem. But I presume it is /etc/certs/asimba.crt. I did use this file but unfortunately the oxauth_script.log now says: ``` 2016-09-17 07:10:04,426 INFO [org.xdi.service.PythonService] (pool-2-thread-1) Saml. Initialization 2016-09-17 07:10:04,534 ERROR [org.xdi.service.custom.script.CustomScriptManager] (pool-2-thread-1) Failed to initialize custom script: 'saml' at sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:108) ... java.security.cert.CertificateException: java.security.cert.CertificateException: Could not parse certificate: java.io.IOException: Empty input at org.python.core.Py.JavaError(Py.java:546) ... Caused by: java.security.cert.CertificateException: Could not parse certificate: java.io.IOException: Empty input at sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:108) ... Caused by: java.io.IOException: Empty input at sun.security.provider.X509Factory.engineGenerateCertificate(X509Factory.java:104) ``` I presume its just the wrong certificate...? I did a research on google about that java exception - didnt help though :( Again, can you help me? Best Markus

By Michael Schwartz Account Admin 17 Sep 2016 at 11:58 a.m. CDT

Michael Schwartz gravatar
Zico, Can you help Markus with his question. I'm not sure about the answer... - Mike

By Mohib Zico staff 17 Sep 2016 at 12:11 p.m. CDT

Mohib Zico gravatar
>> I dont have a /etc/certs/saml.pem. But I presume it is /etc/certs/asimba.crt. Yes, that's correct. The 'saml.pem' is 'asimba.crt' but you need to remove `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----` part from that crt. Just keep the certificate section without that header and footer.

By Markus Thielen user 18 Sep 2016 at 4:17 a.m. CDT

Markus Thielen gravatar
Awesome! That worked. Thank you very much. Now I get to the Login Screen of the proxied IDP (which is another Gluu server). Thats a big step forward. Unfortunately I cannot login with any user of it. The log in /opt/idp/logs/idp-process.log (with level=TRACE) shows me the error: ``` 08:54:29.923 - DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:164] - Error occured attempting authentication javax.naming.directory.InvalidSearchFilterException: invalid attribute description at com.sun.jndi.ldap.Filter.encodeSimpleFilter(Filter.java:446) ~[na:1.8.0_03-Ubuntu] ... 08:54:29.928 - TRACE [edu.vt.middleware.ldap.jaas.LdapLoginModule:264] - Begin abort 08:54:29.935 - INFO [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginServlet:194] - User authentication for test failed javax.security.auth.login.LoginException: invalid attribute description at edu.vt.middleware.ldap.jaas.LdapLoginModule.login(LdapLoginModule.java:167) ~[vt-ldap-3.3.9.jar:na] ``` (full stack in link url) The LDAP filter: ``` 08:54:29.820 - DEBUG [edu.vt.middleware.ldap.auth.SearchDnResolver:195] - filter = (={0}) ``` Which might be the problem? Do you have any idea what I have missed? Btw the URL of the login screen is: https://<gluu-server-2>/idp/Authn/UserPassword and it looks like: http://easycaptures.com/fs/uploaded/1062/4829989741.png

By Mohib Zico staff 18 Sep 2016 at 10:59 a.m. CDT

Mohib Zico gravatar
>> Unfortunately I cannot login with any user of it. What do you see in oxauth.log? >> Btw the URL of the login screen is: https://<gluu-server-2>/idp/Authn/UserPassword and it looks like: http://easycaptures.com/fs/uploaded/1062/4829989741.png Try to remove Username/Password login handler for Shibboleth, if there is any. You will get login handler configurations in /opt/tomcat/conf/shibboleth/idp/handler.xml.vm. After commenting out U/P login handler, bounce tomcat service one time.

By Markus Thielen user 18 Sep 2016 at 1:35 p.m. CDT

Markus Thielen gravatar
Nothing was written to either oxauth.logs of both servers. So I removed the U/P Login handler from the second gluu server to which asimba is redirecting to. Now I get forwarded to the "normal" gluu login page and the login is working. Thank you for this! After the successful login I got forwarded to the first gluu server (the proxy one). The page says "Failed to authenticate" and is located at <gluu-1>/oxauth/error.htm?cid=106. oxauth.log says: ``` 2016-09-18 18:23:10,904 ERROR [org.xdi.oxauth.service.external.ExternalAuthenticationService] Traceback (most recent call last): File "<iostream>", line 268, in authenticate AttributeError: 'NoneType' object has no attribute 'entrySet' at org.python.core.Py.AttributeError(Py.java:205) ... ``` oxauth_script.logs says: ``` 2016-09-18 18:23:00,462 INFO [org.xdi.service.PythonService] (ajp-bio-127.0.0.1-8009-exec-38) Saml. Prepare for step 1 2016-09-18 18:23:00,468 INFO [org.xdi.service.PythonService] (ajp-bio-127.0.0.1-8009-exec-38) Saml. Prepare for step 1. Prepared assertionConsumerServiceUrl: 'https://<gluu-1>/oxauth/postlogin' 2016-09-18 18:23:00,502 INFO [org.xdi.service.PythonService] (ajp-bio-127.0.0.1-8009-exec-38) Saml. Prepare for step 1. external_auth_request_uri: 'https://<gluu-1>/asimba/profiles/saml2/sso/web ?SAMLRequest=...' 2016-09-18 18:23:10,880 INFO [org.xdi.service.PythonService] (ajp-bio-127.0.0.1-8009-exec-38) Saml. Authenticate for step 1 2016-09-18 18:23:10,884 INFO [org.xdi.service.PythonService] (ajp-bio-127.0.0.1-8009-exec-38) Saml. Authenticate for step 1. saml_response: '...' 2016-09-18 18:23:10,895 INFO [org.xdi.service.PythonService] (ajp-bio-127.0.0.1-8009-exec-38) Saml. Authenticate for step 1. saml_response_name_id: '_2f22f2d8ffa01d566b2c15d02edbc3a7!https://<gluu-1>/saml' 2016-09-18 18:23:10,898 INFO [org.xdi.service.PythonService] (ajp-bio-127.0.0.1-8009-exec-38) Saml. Authenticate for step 1. attributes: '{country: [Netherlands]}' 2016-09-18 18:23:10,899 INFO [org.xdi.service.PythonService] (ajp-bio-127.0.0.1-8009-exec-38) Saml. Authenticate for step 1. Attempting to find user by oxExternalUid: saml: '_2f22f2d8ffa01d566b2c15d02edbc3a7!https://<gluu-1>/saml' 2016-09-18 18:23:10,903 INFO [org.xdi.service.PythonService] (ajp-bio-127.0.0.1-8009-exec-38) Saml. Authenticate for step 1. There is no user in LDAP. Adding user to local LDAP 2016-09-18 18:23:10,904 INFO [org.xdi.service.PythonService] (ajp-bio-127.0.0.1-8009-exec-38) Saml. Authenticate for step 1. Using next attributes mapping 'None' ``` Funny though there's the country=Netherlands again. Thanks for all your time helping me :)

By Mohib Zico staff 18 Sep 2016 at 1:58 p.m. CDT

Mohib Zico gravatar
SAML Script not loading properly. We are going to publish new doc on this issue; it will be able to fix your issue. Stay tuned.

By Markus Thielen user 18 Sep 2016 at 2:01 p.m. CDT

Markus Thielen gravatar
Awesome! Thank you.

By Markus Thielen user 22 Sep 2016 at 3:31 a.m. CDT

Markus Thielen gravatar
Hi again, Is it possible to set up some kind of routing between SPs and the target IDP? (speaking about SAML) So I would be able to do something like * SP1 => Gluu1 (act as Proxy) => Target-IDP * SP2 => Gluu1 (authenticate directly) From my understanding I can only set the "Authentication mode" globally to the Custom script (saml) which then always forwards the authentication to the Target-IDP. I would like to configure the authentication mode per SP though. Best Markus

By Mohib Zico staff 22 Sep 2016 at 4:35 a.m. CDT

Mohib Zico gravatar
Hello Markus, >> Is it possible to set up some kind of routing between SPs and the target IDP? (speaking about SAML) Are we talking about [this](https://gluu.org/docs/integrate/inbound-saml/#add-selectors)?

By Markus Thielen user 22 Sep 2016 at 4:57 a.m. CDT

Markus Thielen gravatar
Hello Zico, Yea, initially I thought that's just what I wanted, but after reading the SAML proxy solution link from Mike (https://ox.gluu.org/doku.php?id=asimba:setup_testing) it looks like I have to set up a selector between the Proxy-Gluu-Server and the Target-IDP as a whole. I'm confused. So right now I have set up a SP Requestor with the entity id <gluu-1>/saml which targets the remote IDP. Instead, can I just create a new Requestor <sp1> that targets the remote IDP? Best Markus

By Mohib Zico staff 22 Sep 2016 at 5:06 a.m. CDT

Mohib Zico gravatar
>> can I just create a new Requestor <sp1> that targets the remote IDP? Yes, possible. You need to prepare your SSO without saml_script then. You can follow [this](https://gluu.org/docs/integrate/inbound-saml/) doc.

By Markus Thielen user 22 Sep 2016 at 6:33 a.m. CDT

Markus Thielen gravatar
Ok, did this. And I also disabled the SP in SAML/Outbound/Trust Relationships. Now it says: ``` Error Message: SAML 2 SSO profile is not configured for relying party <sp> ``` If I let it enabled it continues to authenticate normally against the first gluu server. Do I have to give the SP other metadata? It still has the metadata from https://<gluu-1>/idp/shibboleth.

By Michael Schwartz Account Admin 22 Sep 2016 at 12:09 p.m. CDT

Michael Schwartz gravatar
We would probably need a gotomeeting to resolve this. Inbound SAML is complex, and I'm not sure based on this thread exactly which part is problematic. I'm not even sure you have the right design. Does your requirement look something like this: !(https://ox.gluu.org/lib/exe/fetch.php?media=oxauth:lda.png)

By Michael Schwartz Account Admin 22 Sep 2016 at 12:16 p.m. CDT

Michael Schwartz gravatar
See attached diagram to this commment : lda.png

By Mohib Zico staff 22 Sep 2016 at 12:17 p.m. CDT

Mohib Zico gravatar
>> And I also disabled the SP in SAML/Outbound/Trust Relationships. Sorry, not clear. What did you do? Here is a quick view if you *only* use Asimba ( not saml script ): - You need to configure all SPs with SP requestor section. Add every SP in the list. - You need to configure all IDPs in Asimba - All of your remote SPs and IDPs will point to Asimba metadata.

By Markus Thielen user 22 Sep 2016 at 1:01 p.m. CDT

Markus Thielen gravatar
I have attached the idea as a diagram. @Zico: What I meant was, I have created a TrustRelationship (under SAML/Outbound in oxTrust) for the SP. And I thought I might have to disable it to work with asimba. But I still used the shibboleth metadata so that could not work. Now, I try to set up my SP to use the Asimba metadata - lets see how this works. Thank you

By Markus Thielen user 22 Sep 2016 at 1:03 p.m. CDT

Markus Thielen gravatar
Please have a look at the diagram. Maybe I'm just wrong with all of it and should stop experimenting before I become mental.

By Michael Schwartz Account Admin 22 Sep 2016 at 1:28 p.m. CDT

Michael Schwartz gravatar
Yes, we don't recommend this configuration, although it may work. If you look at the diagram I attached, we only configure one SP to point at the Asimba IDP interface: oxAuth. Specifically, we use the SAML custom authentication script as the SP. We are really using Asimba just as a gateway for inbound SAML IDP connections. When the user returns from their home IDP with an assertion that includes attributes, we dynamically create a local record for that person in LDAP. For internal SAML applications, we use the Shibboleth IDP as the interface. Or applications can use OpenID Connect to oxAuth. The reason for this is that Asimba doesn't have good control over attribute release policies. Also, without this approach, there would be no support for OpenID Connect websites. This method also enables addition information to be collected about the person (calls to API's, or dynamically generated attributes).

By Mohib Zico staff 22 Sep 2016 at 1:28 p.m. CDT

Mohib Zico gravatar
Thanks for sharing the diagram. This is pretty straight forward SAML Proxy workflow. Let's fix a call as Mike mentioned and we will be able to discuss.

By Michael Schwartz Account Admin 22 Sep 2016 at 2:13 p.m. CDT

Michael Schwartz gravatar
Zico and I discussed. Per my previous comment, we don't like connecting the SP's directly to Asimba. If you want to schedule a meeting, my calendar is open at http://gluu.org/booking and we can go over our preferred solution.

By Michael Schwartz Account Admin 03 Oct 2016 at 10:58 a.m. CDT

Michael Schwartz gravatar
Per our conversation, we are updating the docs. But this page is a [draft of the changes](https://github.com/GluuFederation/docs/blob/master/sources/how-to/saml_proxy_end_to_end.md)