Gluu IDP error - No potential flows left to choose from, authentication will fail

By: Bjorn Skobba user 12 Jul 2017 at 6:51 a.m. CDT

19 Responses
Bjorn Skobba gravatar
Hi, I'm trying to set up Apache Shibboleth SP and using Gluu IDP as my IDP. I have looked at the examples in the [documentation](https://gluu.org/docs/ce/3.0.2/integration/webapps/saml-sp/), and also tried other sources (google...), but with no real luck. When accessing my SP i get redirected to oxauth/login in my gluu server, I provide a username and password, and get redirected back to my SP (/Shibboleth.sso/SAML2/POST), but with the error: ``` opensaml::FatalProfileException The system encountered an error at Wed Jul 12 13:40:43 2017 To report this problem, please contact the site administrator at support@xxxxx.yyy. Please include the following message in any email: opensaml::FatalProfileException at (https://qvi-test-shib.forlagssentralen.no:444/Shibboleth.sso/SAML2/POST) SAML response reported an IdP error. Error from identity provider: Status: urn:oasis:names:tc:SAML:2.0:status:Requester Sub-Status: urn:oasis:names:tc:SAML:2.0:status:AuthnFailed Message: authn ``` The following is logged in the idp-logs: ``` 2017-07-12 09:03:26,522 - ERROR [org.gluu.oxauth.client.validation.OAuthValidationFilter:153] - validate token status message:The request is missing a required parameter, includes an unsupported parameter or parameter value, repeats a parameter, includes multiple credentials, utilizes more than one mechanism for authenticating the client, or is otherwise malformed. 2017-07-12 09:03:26,522 - ERROR [org.gluu.oxauth.client.validation.OAuthValidationFilter:180] - Token validation failed. User is NOT logged in 2017-07-12 09:03:26,533 - ERROR [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:296] - Profile Action SelectAuthenticationFlow: No potential flows left to choose from, authentication will fail 2017-07-12 09:03:26,538 - WARN [org.opensaml.profile.action.impl.LogEvent:76] - An error event occurred while processing the request: NoPotentialFlow ``` Complete logs are attached. I am pretty sure it is something obvious I have missed, but I have to reach out for help after spending a lot of time trying to figure it out on my own. Any pointers to what I can try/check/fix is highly appreciated. Many thanks Bjørn
OS Version : N/A
closed

Answers

By Aliaksandr Samuseu staff 12 Jul 2017 at 10:46 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
Hi, Bjorn. That's strange. I haven't met any issues with SAML TRs in 3.0.2 so far (aside from [this known bug](https://github.com/GluuFederation/oxTrust/issues/490) which can be circumvented) if it's a newly installed one. But we have a report from another user who seems to have issue exactly like yours. The only thing is that their instance undergone upgrade from 2.4.4 to 3.0.2, and we thought it probably was the cause of it. Did you also upgrade your instance from 2.4.4, or is it a newly installed 3.0.2 instance? Could you also provide screenshots of this TR's settings (from web UI) and SP's metadata it uses? Anything special about it, in general? Like, perhaps, you had to add some customizations to IdP's configuration files on disk?

By Aliaksandr Samuseu staff 12 Jul 2017 at 10:47 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
Sorry, I see you've provided SP's metadata and TR's screenshot already.

By Aliaksandr Samuseu staff 12 Jul 2017 at 11:01 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
Judging by your last post in [this ticket](https://support.gluu.org/authentication/4241/hotptopt-authentication-module-invalid-barcode/#at23952) it appears you indeed have upgraded it recently. Could you provide a brief list of steps you used to upgrade it, as well as refer me to docs page you used?

By Bjorn Skobba user 13 Jul 2017 at 6:07 a.m. CDT

Copy
Bjorn Skobba gravatar
Hi, Thanks for your reply. I have upgraded from 3.0.1 -> 3.0.2 basically following the docs [here](https://gluu.org/docs/ce/3.0.2/upgrade/). Just using the export/import scripts for 3.0 (export30.py/import30.py) Many thanks Bjørn

By Mohib Zico Account Admin 26 Jul 2017 at 7:27 a.m. CDT

Copy
Mohib Zico gravatar
Hello Bjorn, How is it going? Is that problem still bothering you?

By Bjorn Skobba user 27 Jul 2017 at 3:17 a.m. CDT

Copy
Bjorn Skobba gravatar
Hi and thanks for your reply. Yes, unfortunately I haven't been able to work around the problem. Any input would be appreciated. Many thanks Bjørn

By Mohib Zico Account Admin 27 Jul 2017 at 4:15 a.m. CDT

Copy
Mohib Zico gravatar
Ok. Can you please share the 'shibboleth2.xml' file of your SP and paste the result of 'ls -l' inside /etc/shibboleth/ here?

By Bjorn Skobba user 27 Jul 2017 at 6:07 a.m. CDT

Copy
Bjorn Skobba gravatar
Hi, I have uploaded shibbolet2.xml to the dropbox folder (see link ). In the SP /etc/shibboleth/attribute-map.xml, I have added: ``` <Attribute name="urn:oid:0.9.2342.19200300.100.1.1" id="uid"/> <Attribute name="urn:oid:0.9.2342.19200300.100.1.3" id="mail"/> ``` The requested output: ``` root@server:/etc/shibboleth# ls -l total 192 -rw-r--r-- 1 root root 865 Aug 12 2015 accessError.html -rw-r--r-- 1 root root 1480 Aug 12 2015 attrChecker.html -rw-r--r-- 1 root root 8605 Jul 13 13:00 attribute-map.xml -rw-r--r-- 1 root root 8447 Jul 11 12:40 attribute-map.xml.ORIG -rw-r--r-- 1 root root 3055 Aug 12 2015 attribute-policy.xml -rw-r--r-- 1 root root 1895 Aug 12 2015 bindingTemplate.html -rw-r--r-- 1 root root 1210 Aug 12 2015 console.logger -rw-r--r-- 1 root root 1689 Aug 12 2015 discoveryTemplate.html -rw-r--r-- 1 root root 10140 Aug 12 2015 example-metadata.xml -rw-r--r-- 1 root root 14670 Aug 12 2015 example-shibboleth2.xml -rw-r--r-- 1 root root 870 Aug 12 2015 globalLogout.html -rw-r--r-- 1 root root 10104 Jul 11 13:14 idp-metadata.xml -rw-r--r-- 1 root root 666 Aug 12 2015 localLogout.html -rw-r--r-- 1 root root 1140 Aug 12 2015 metadataError.html -rw-r--r-- 1 root root 2559 Jul 12 11:01 native.logger -rw-r--r-- 1 root root 681 Aug 12 2015 partialLogout.html -rw-r--r-- 1 root root 1304 Aug 12 2015 postTemplate.html -rw-r--r-- 1 root root 2318 Aug 12 2015 protocols.xml -rw-r--r-- 1 root root 1255 Aug 12 2015 security-policy.xml -rw-r--r-- 1 root root 1256 Aug 12 2015 sessionError.html -rw-r--r-- 1 root root 14749 Jul 13 13:00 shibboleth2.xml -rw-r--r-- 1 root root 5947 Jul 11 12:40 shibboleth2.xml.ORIG -rw-r--r-- 1 root root 3019 Jul 12 11:00 shibd.logger -rw-r--r-- 1 root root 1192 Jul 11 13:20 sp-cert.pem -rw------- 1 root root 1704 Jul 11 13:20 sp-key.pem -rw-r--r-- 1 root root 898 Aug 12 2015 sslError.html -rw-r--r-- 1 root root 1252 Aug 12 2015 syslog.logger -rw-r--r-- 1 root root 23671 Aug 12 2015 upgrade.xsl ```
Video or screenshot link

By Mohib Zico Account Admin 27 Jul 2017 at 6:16 a.m. CDT

Copy
Mohib Zico gravatar
Thanks. We will check and get back to you with our suggestions.

By Mohib Zico Account Admin 27 Jul 2017 at 4:01 p.m. CDT

Copy
Mohib Zico gravatar
Ok, there might be couple of places you need to work on. Let's start with SP first. Sharing a test shibboleth2.xml from one test SP. You just need to change below syntax according to your own setup. : - `ApplicationDefaults entityID="https://sp.gluu.org/shibboleth"` - `SSO entityID="https://allinone3.gluu.org/idp/shibboleth` - `MetadataProvider type="XML" file="allinone3_metadata.xml"` Here is the file: https://pastebin.com/f1GLASc3

By Bjorn Skobba user 28 Jul 2017 at 2:34 a.m. CDT

Copy
Bjorn Skobba gravatar
Thanks, I have now used the sample shibboleth2.xml file from the pastebin, and edited the syntax to suit my setup. I restarted shibd and downloaded the SP-metadata from https://<sp>/Shibboleth.sso/Metadata The SP-metadata file was then used to create a new Trust relationship in gluu. Unfortunately, I have the exact same error messages and behaviour as before. In the browser: ``` opensaml::FatalProfileException at (https://qvi-test-shib.forlagssentralen.no:444/Shibboleth.sso/SAML2/POST) SAML response reported an IdP error. Error from identity provider: Status: urn:oasis:names:tc:SAML:2.0:status:Requester Sub-Status: urn:oasis:names:tc:SAML:2.0:status:AuthnFailed Message: authn ``` The debug logs from the IDP and the SP are available here: https://pastebin.com/HSJ7vjRD Cheers Bjørn

By Mohib Zico Account Admin 28 Jul 2017 at 4:03 a.m. CDT

Copy
Mohib Zico gravatar
That's fine, it's just the start of troubleshooting. One quick question, did you change any configuration file/s by yourself in your Gluu Server?

By Bjorn Skobba user 28 Jul 2017 at 4:33 a.m. CDT

Copy
Bjorn Skobba gravatar
For the troubleshooting we're doing now, nothing is changed "by hand" in the gluu server config files. However, during troubleshooting on my own earlier, I did try to modifiy ```opt/shibboleth-idp/conf/idp.properties``` by changing ``` idp.authn.flows = RemoteUser ``` to ``` idp.authn.flows = Password|RemoteUser ``` The result was somewhat interesting.... When accessing the URL to my protected site I got redirected to the IDP as usual. After providing the credentials, I got a new redirect to ```https://<idp>/idp/profile/SAML2/Redirect/SSO?execution=e1s2``` and then providing the credentials again, I reached the protected page. So it worked - sort of. But as I had to manually change idp.properties and I got "double" authentication" it didn't seem the right path. I have uploaded screenshots of the steps outlined above to the dropbox share as step{1,2,3}.png Thanks Bjørn
Video or screenshot link

By Mohib Zico Account Admin 28 Jul 2017 at 4:46 a.m. CDT

Copy
Mohib Zico gravatar
Would you mind if I request you to install a brand new Gluu Server and just use default settings; then we will move forward from there? Custom settings are something which require lot of time and isn't covered in community support.

By Bjorn Skobba user 28 Jul 2017 at 5:49 a.m. CDT

Copy
Bjorn Skobba gravatar
OK, I can do that. The idp.properties file was reverted as I said, so not sure a new setup would change anything, but I can give it a go. To make sure I don't do any configuration mistakes, do you have a more complete or up to date description on how to set up shibboleth on the SP? As in shibboleth2.xml, how to generate the SP-metadata, and (if any special) settings for the Trust relationship setup in Gluu IdP BR Bjørn

By Mohib Zico Account Admin 28 Jul 2017 at 5:55 a.m. CDT

Copy
Mohib Zico gravatar
>> the idp.properties file was reverted as I said, so not sure a new setup would change anything, The thing is... Gluu Server is really HUGE; whenever we make any changes... we need to make sure that... these are also reflected inside LDAP or so; then comes specific service restart etc. That's why requested to move forward with default setup; default setup is sufficient enough in this case. >> As in shibboleth2.xml, how to generate the SP-metadata, and (if any special) settings for the Trust relationship setup in Gluu IdP You don't need to generate metadata for SP. If you install shibboleth sp there, it will automatically create it's own data ( including metadata ). You can grab that metadata with https://hostname_of_sp/Shibboleth.sso/Metadata

By Bjorn Skobba user 28 Jul 2017 at 8:21 a.m. CDT

Copy
Bjorn Skobba gravatar
Hi, not sure if it is good or bad...but I got it to work with the fresh install. Slightly confused to why, and will have to dig further and also try to make it work in the original test environment where we had another working Trust Relationship running already. Thanks for helping me in the right direction. I suppose this ticket may be closed. BR Bjørn

By Aliaksandr Samuseu staff 28 Jul 2017 at 9:04 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
>The result was somewhat interesting.... When accessing the URL to my protected site I got redirected to the IDP as usual. After providing the credentials, I got a new redirect to https://<idp>/idp/profile/SAML2/Redirect/SSO?execution=e1s2 and then providing the credentials again, I reached the protected page. That's strange. And using >idp.authn.flows = Password|RemoteUser at SP - won't it try to solicit "UsernamePassword" login handler which we don't support, and which should be removed long ago? Did both those authentication attempts use different login pages, Bjorn? Of was it standard oxAuth's login page both times?

By Bjorn Skobba user 31 Jul 2017 at 1:36 a.m. CDT

Copy
Bjorn Skobba gravatar
Hi Aliaksandr, not sure if it works to reply to a closed ticket.... :) The login pages were as shown in the files "step{1,2}.png" uploaded to the dropbox share. Basically the first login attempt used the standard oxAuth page and the second login attempt used a different one. Not sure how this all makes sense ;) BR Bjørn

Post an answer