relay state transfer from SP to Asimba via interception

By: Hugo Brakman user 28 Feb 2017 at 9:01 a.m. CST

10 Responses
Hugo Brakman gravatar
Dear support, We have a setup of multiple SP -> Shibboleth -> Interception script -> Asimba -> multiple IDP This setup was recommended by Gluu earlier for our situation. For one of the SP, within Asimba, we need to restrict the list of IDPs that are shown in the selector.jsp based on the exact webpage that is requested. For example, the user browses to "test.com/X", in which case we want to show IDPx and IDPz. If the user browses to test.com/Y, we want to show IDPy and IDPz. With a previous setup where SPs and IDPs were directly connected to Asimba, we could use the "relaystate" request parameter that is passed from the SP to Asimba. It is possible to configure the SP to pass this in plain text and in that case the value was "test.com/X". With it, I can filter everything except IDPx and IDPz. With the new configuration, where Shibboleth with the interception script are positioned between the SPs and Asimba, the relay state is not passed to Asimba anymore. It seems it is stored earlier and a cookie is used to find it back later. There is a setting in Gluu's shibboleth2/sp/shibboleth2.xml.vm about the relaystate. It defaults to cookie, we can leave it empty and it should then pass the value in plain text. However, changing this does not seem to have an effect. (Note that I am talking about the file on the Gluu server and not about the SP on the website, where it does have the desired effect) Also I checked what I can do from within the interception script. I am able to pass information from there to asimba via request parameters. However I seem to have lost the relaystate parameter already at this point or at least did not find out how to access it. Can you give advice on how to pass this information from the SP to Asimba? For completeness, here are the redirections as seen at the browser: https://webserver/secure is protected by the SP and redirects to https://gluu/idp/profile/SAML2/Redirect/SSO (with the relay state in plain text) This one seems to set the cookie and stop passing the parameter https://gluu/idp/AuthnEngine https://gluu/idp/Authn/RemoteUser https://gluu/oxauth/seam/resource/restv1/oxauth/authorize https://gluu/oxauth/authorize https://gluu/oxauth/auth/saml/samllogin-login This is where the interception script seems executed and I need access to the value that the SP sent earlier https://gluu/asimba/profiles/saml2/sso/web This is where I need to use the value Regards, Hugo
CentOS72
closed

Answers

By Mohib Zico staff 08 Mar 2017 at 4:47 a.m. CST

Copy
Mohib Zico gravatar
Hi Hugo, Please correct me if I am wrong... here is what you want? - Three SPs: - test.com/X - test.com/Y - test.com/Z - 'test.com/Z' will present full asimba discovery page from where user can select their own IDP. - 'test.com/Y' and 'test.com/X' will show either a new discovery page OR will sort out 2-3 IDPs from actual discovery page and will present to users.

By Hugo Brakman user 08 Mar 2017 at 5:17 a.m. CST

Copy
Hugo Brakman gravatar
Hi Mohib, The scenario you describe is a bit different. Let me state it again, based on your format. We have multiple SPs but the case regarding the relay state is within one SP of webserver "test.com", that has 3 pages. One single SP with two pages within the webserver: test.com/X -> asimba discovery page where IDP X and Z can be selected test.com/Y -> asimba discovery page where IDP X and Z can be selected In the fuller scenario there will also be another SP "SPX" that leads to a discovery page with IDP X and Z. Regards, Hugo

By Mohib Zico staff 08 Mar 2017 at 5:19 a.m. CST

Copy
Mohib Zico gravatar
Okay.. . Seems like you are looking for applicationoverride from SP side?

By Hugo Brakman user 08 Mar 2017 at 5:41 a.m. CST

Copy
Hugo Brakman gravatar
Hi Mohib, That looks promising. I'll have to really dig in to see if it fully answers the question. Maybe you know at least these two: 1) if we separate by "application" within this single webserver, will have have that "entityID" in asimba or will it not be passed by the Gluu IDP with interception script to Asimba? 2) it sounds like this requires a restart whenever a /X or /Y is added to the server. This would be a severe drawback for us. 3) Do you know of any other way we can pass such "resource" information to Asimba or is your suggestion really the only way to go? Regards, Hugo

By Mohib Zico staff 08 Mar 2017 at 7:10 a.m. CST

Copy
Mohib Zico gravatar
>> 1) if we separate by "application" within this single webserver, will have have that "entityID" in asimba or will it not be passed by the Gluu IDP with interception script to Asimba? Asimba / Gluu Server will know them as 'different SP'. So you will configure those entityIDs just like same way you configure other SPs inside Gluu Server. >> 2) it sounds like this requires a restart whenever a /X or /Y is added to the server. This would be a severe drawback for us. Restart means? >> 3) Do you know of any other way we can pass such "resource" information to Asimba or is your suggestion really the only way to go? I would start with Application Override, first. But as this is SP setup.. you might wanna consult with Shibboleth documentation on SP setup.

By Hugo Brakman user 08 Mar 2017 at 8:10 a.m. CST

Copy
Hugo Brakman gravatar
Restart means restart of the webserver or the SP on that side. Anyway thanks for the input. We'll look into it. You can close the issue if you don't want it to stay open. We'll post the results here in either case.

By Mohib Zico staff 08 Mar 2017 at 8:46 a.m. CST

Copy
Mohib Zico gravatar
I was thinking about your X/Y issue and another way we can achieve that. Though the feature named 'selector' is not included in latest Gluu Servers but here is how it used to work... ``` <?xml version="1.0" encoding="UTF-8"?> <asimba-selector> <application entityId="https://gluu-sp.gluu.org/secure" organizationId="https://idp1.gluu.org/idp/shibboleth" /> <application entityId="https://gluu-sp.gluu.org/oxHelloWorld" organizationId="https://idp2.gluu.org/idp/shibboleth" /> </asimba-selector> ``` Translation: 'gluu-sp.gluu.org/secure' and 'gluu-sp.gluu.org/oxHelloWorld' are configured there. Whenever end user will hit '/secure' link... Gluu Server will automatically send user to 'idp1.gluu.org'; no selector or Asimba discovery page for these users. Same for 'oxHelloWorld' users.. it will go to 'idp2.gluu.org' as well directly.

By Hugo Brakman user 08 Mar 2017 at 9:15 a.m. CST

Copy
Hugo Brakman gravatar
Hi Mohib, Your reply just now looks related to the feature in Gluu where you tie an SP directly to and IDP. In our case that will not work as there will always be a minimum of 2 IDPS per SP and per resource such as /secure We are now investigating if we can put a page between the SP and Gluu such that we can store the information for Asimba to pick up later (e.g. by cookie). Your earlier application suggestion is probably nicer if it can work in our case, but putting something in front is possibly quite fast to implement as an initial solution. Keep you posted.

By Yuriy Movchan staff 15 Jun 2017 at 1:25 p.m. CDT

Copy
Yuriy Movchan gravatar
I've built idp.war 2.4.4_sp4 with update which pass relyingPartyId from IDP to oxAuth in authorization request. Now yo can get in script origin_headers from session. Here is example: ``` {"scope":"openid profile email user_name","response_type":"code id_token","origin_headers":"https://sp.gluu.org/shibboleth","nonce":"nonce","redirect_uri":"https://nest.gluu.org/idp/auth-code.jsp","remote_ip":"192.168.15.1","auth_step":"1","client_id":"@!6BED.0CBA.D569.AA67!0001!6E3D.B9BF!0008!082F.319E","acr":"internal"} ``` Here is code in the script code to get it: ``` context = Contexts.getEventContext() session_attributes = context.get("sessionAttributes") if session_attributes.containsKey("origin_headers): origin_headers = session_attributes.get("origin_headers") ```

By Hugo Brakman user 20 Jun 2017 at 2:43 a.m. CDT

Copy
Hugo Brakman gravatar
Hi Yuriy, Sorry for the late reply. I am up to my neck in other urgent things. I have seen this sp4 work from the context of the other issue (of getting the SP id to the interception script). Please note that the relay state is something else (see https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions the parameter relaystate). Are you expecting also this parameter is passed via the session attributes? I'll test it myself as soon as I have a chance as it would make the user experience a lot more smooth if we can retrieve this value in the interception script. Regards, Hugo

Post an answer