Log in to AnswerLog in to Follow
2017-08-29 13-22-41
Daniel Brooks
410Views
16Comments
Solved
[IdP] Okta IdP integration: "UNABLE TO PROCESS REQUEST"
Question
Forge
idp
Web icon
IdP
Forge component by João Barata

Hello,

When I set up our application in Okta, I get 

UNABLE TO PROCESS REQUEST

Unable to process SAML Logout response message

This occurs after logging in.  For some reason it seems like it is trying to log out.  I attached the SAML response for your review.


The error logged is: "ResponseId was not previous registered."


I'm not sure what I'm doing wrong.

Thank you

response_saml.xml
0
0
22 Feb 2019
2017-02-16 19-26-26
Telmo Martins
Staff
Solution

Hi Daniel,

Yes. and from OKTA perspective it's the ACS URL.

If the okta version that you are using supports the importation of a SP xml metadata file, you can download that SP xml in the IdP component and import it on Okta and should be fine.
Otherwise, you should be able to set the ACS URL manually to SSO.aspx on OKTA configuration console,


Regards

See solution in context
1
0
22 Feb 2019

Telmo Martins wrote:

Hi Daniel,

Yes. and from OKTA perspective it's the ACS URL.

If the okta version that you are using supports the importation of a SP xml metadata file, you can download that SP xml in the IdP component and import it on Okta and should be fine.
Otherwise, you should be able to set the ACS URL manually to SSO.aspx on OKTA configuration console,


Regards


Thank you!  I'll get back to you after we alter that and then mark this as the solution if all goes well.

Thanks again


0
0
22 Feb 2019

Telmo Martins wrote:

Hi Daniel,

Yes. and from OKTA perspective it's the ACS URL.

If the okta version that you are using supports the importation of a SP xml metadata file, you can download that SP xml in the IdP component and import it on Okta and should be fine.
Otherwise, you should be able to set the ACS URL manually to SSO.aspx on OKTA configuration console,


Regards


Ok, looks like that worked just fine.  Although the claims aren't coming across (just the email).

I added the claims as suggested in this guide:

https://devforum.okta.com/t/how-to-configure-claim-attributes-in-okta-for-saml-2-0-sp/3969


Do you have an example of what the Claims on the Okta side look like to match the Outsystems IdP side?

Thanks!

0
0
22 Feb 2019

Hi Daniel,

The message content it's regarding a "LoginResponse", however it's seems that it's being sent to the IdP connector "LogoutEndpoint" instead of ACS ("LoginResponse") endpoint.

Please review the configuration on IdP server end, to send the Assertion to the correct URL. Ie, instead of .../IdP/SLO.aspx, it should be sent to .../IdP/SSO.aspx


Regards

0
0
22 Feb 2019

Telmo Martins wrote:

Hi Daniel,

The message content it's regarding a "LoginResponse", however it's seems that it's being sent to the IdP connector "LogoutEndpoint" instead of ACS ("LoginResponse") endpoint.

Please review the configuration on IdP server end, to send the Assertion to the correct URL. Ie, instead of .../IdP/SLO.aspx, it should be sent to .../IdP/SSO.aspx


Regards

Hello Telmo,

The /IdP/SSO.aspx should be set on the Okta side?

0
0
22 Feb 2019
2017-02-16 19-26-26
Telmo Martins
Staff
Solution

Hi Daniel,

Yes. and from OKTA perspective it's the ACS URL.

If the okta version that you are using supports the importation of a SP xml metadata file, you can download that SP xml in the IdP component and import it on Okta and should be fine.
Otherwise, you should be able to set the ACS URL manually to SSO.aspx on OKTA configuration console,


Regards

1
0
22 Feb 2019

Telmo Martins wrote:

Hi Daniel,

Yes. and from OKTA perspective it's the ACS URL.

If the okta version that you are using supports the importation of a SP xml metadata file, you can download that SP xml in the IdP component and import it on Okta and should be fine.
Otherwise, you should be able to set the ACS URL manually to SSO.aspx on OKTA configuration console,


Regards


Thank you!  I'll get back to you after we alter that and then mark this as the solution if all goes well.

Thanks again


0
0
22 Feb 2019

Telmo Martins wrote:

Hi Daniel,

Yes. and from OKTA perspective it's the ACS URL.

If the okta version that you are using supports the importation of a SP xml metadata file, you can download that SP xml in the IdP component and import it on Okta and should be fine.
Otherwise, you should be able to set the ACS URL manually to SSO.aspx on OKTA configuration console,


Regards


Ok, looks like that worked just fine.  Although the claims aren't coming across (just the email).

I added the claims as suggested in this guide:

https://devforum.okta.com/t/how-to-configure-claim-attributes-in-okta-for-saml-2-0-sp/3969


Do you have an example of what the Claims on the Okta side look like to match the Outsystems IdP side?

Thanks!

0
0
22 Feb 2019

Hi Daniel,

At least in the version I used it's here (Attribute Statements).


Then just make sure to map the Name with the same value on the IdP configurator (Claims configuration)

Regards

0
0
25 Feb 2019

Telmo Martins wrote:

Hi Daniel,

At least in the version I used it's here (Attribute Statements).


Then just make sure to map the Name with the same value on the IdP configurator (Claims configuration)

Regards


Hi Telmo,


After configuration both at the application and Okta, the Okta redirected me to the Service Center login Page.

And after debugging, I noticed that it never went through the no-permission part... Below I attached screenshots of configuration on both ends, can you guys help to identify the problem? Many thanks.




Okta Setting:

0
0
04 Mar 2019

Hi Andy,

The configuration seems fine. However the print-screens you posted regarding debugging in Service Studio are before the login request is send to Okta.

So, you are redirected to okta and after login on OKTA you are redirected to ServiceCenter, is that it?
Or you are never redirected to OKTA to perform login?

From your configuration Okta definitely should sent the message for SSO.aspx, which in fact is the IdP screen.

From the browser developer tools can you confirm to exactly which URL Okta is redirecting the browser.


Regards   

0
0
05 Mar 2019

Telmo Martins wrote:

Hi Andy,

The configuration seems fine. However the print-screens you posted regarding debugging in Service Studio are before the login request is send to Okta.

So, you are redirected to okta and after login on OKTA you are redirected to ServiceCenter, is that it?
Or you are never redirected to OKTA to perform login?

From your configuration Okta definitely should sent the message for SSO.aspx, which in fact is the IdP screen.

From the browser developer tools can you confirm to exactly which URL Okta is redirecting the browser.


Regards   

Hi Telmo,


Thanks for your reply.

I've redone the configurations both in IdP & Outsystems, and Okta end.


Now something weird happened. If I get into the web application via the web app URL, it will re-direct me to Okta. From there, I'll be directed to the app, which is pretty good and expected.


However, if I go to my Okta dashbaord, and click the app icon, I'll be stuck in a same page as shown below


And I checked the IdP SAML Log, below is the error record.


Any thoughts?


Many thanks,

Andy


0
0
06 Mar 2019

Hi Andy,

Yes, you need to go the IdP connector configuration and activate the flag/checkbox to allow IdP-intitiated logins. It's on the third tab.


Regards.

 

0
0
06 Mar 2019

Telmo Martins wrote:

Hi Andy,

Yes, you need to go the IdP connector configuration and activate the flag/checkbox to allow IdP-intitiated logins. It's on the third tab.


Regards.

 

Hi Telmo,


I did it. Then, getting into the application via URL is still good. But via clicking Okta app icon, it directed me to the login page of Service Center. Feels like the link between IdP and my application is lost in some part.


Just got a question in my mind - do I need to implement the web flow/screen of configuration of IdP inside the application but not just using the IdP application in the development platform? I'm thinking maybe this is the issue?

Also to extend the question, when I have multiple applications in the Outsystems platform, the single IdP application configuration won't be able to fit in, isn't it?


Regards,

Andy


0
0
06 Mar 2019

Hi Andy,

Did not fully understood your first question. If it works via application (SP initiated login, it should also work fine for IdP initiated login. However in an IdP initiated login IdP may not know to where redirect the browser. Kindly check the help message near the checkbox for that configuration: "When activated will allow IdP Server Initiated login, ie, without the need of previouly this connector sends an Authn SAML message. When activated most probably you also want to configure a "Login Default URL""

Meaning that without a "Login Default URL" configured (on the same third tab) the browser most probably will be redirected for "/" URL, which in your installation must being redirected for the service center.  

Regarding the second question, the Single IdP should be enough for all your applications (including multi tenant scenarios).

The use case that in fact it's not supported to use the same IdP application, is when your applications have different UserProviders (the UserProvider of IdP connector must be the same of the applications that rely on it).


Regards

0
0
07 Mar 2019

Telmo Martins wrote:

Hi Andy,

Did not fully understood your first question. If it works via application (SP initiated login, it should also work fine for IdP initiated login. However in an IdP initiated login IdP may not know to where redirect the browser. Kindly check the help message near the checkbox for that configuration: "When activated will allow IdP Server Initiated login, ie, without the need of previouly this connector sends an Authn SAML message. When activated most probably you also want to configure a "Login Default URL""

Meaning that without a "Login Default URL" configured (on the same third tab) the browser most probably will be redirected for "/" URL, which in your installation must being redirected for the service center.  

Regarding the second question, the Single IdP should be enough for all your applications (including multi tenant scenarios).

The use case that in fact it's not supported to use the same IdP application, is when your applications have different UserProviders (the UserProvider of IdP connector must be the same of the applications that rely on it).


Regards

Hi Telmo,


Thank you very much for the tip. Now, both the clicking Okta app icon and typing app URL work fine.

You are right. It is the Login URL in the 3rd panel. I need to populate it with the app URL.


In terms of the unclear part of my previous question, please allow me to clarify it more with example:

Let's say I have two apps in Outsystems - app A and app B.

Correspondingly, I will have two apps created in Okta to talk to app A and B (hopefully I'm correct at this stage..).

Now my confusion is - in the IdP component configuration, the 1st tab can only take metadata file from one Okta app. And in the 3rd tab, if I have populated the login URL with the specific app URL, how can I make the IdP work for both or more applications?


Many thanks,

Andy


0
0
07 Mar 2019

Hi Andy,

Regarding the second question, basically you have two applications in OutSystems, and each one need to use a different IdP Single Sign on URL on OKTA? That use case it's only supported OOB in a multi tenant scenario, meaning that you need a tenant for each application. If you need to use both application on the same tenant the IdP component does not support multiple IdP issuer/SP issuers for the same tenant.

On the other hand, if you need that this two applications must be in different user providers, you need to clone IdP, and two IdP installations, one for each user provider.


Regards

1
0
07 Mar 2019

Telmo Martins wrote:

Hi Andy,

Regarding the second question, basically you have two applications in OutSystems, and each one need to use a different IdP Single Sign on URL on OKTA? That use case it's only supported OOB in a multi tenant scenario, meaning that you need a tenant for each application. If you need to use both application on the same tenant the IdP component does not support multiple IdP issuer/SP issuers for the same tenant.

On the other hand, if you need that this two applications must be in different user providers, you need to clone IdP, and two IdP installations, one for each user provider.


Regards

Hi Telmo,

This dialog with Andy has helped me greatly.  I'm at the same point he was with the default Login URL.

We're using one Okta endpoint for all of our apps.  

If I set a default URL for redirect after login, how would I redirect to another app when we set others up since there's only one redirect URL?


Also, when I set it to the URL of one of our apps, we get this after login:

It just hangs here with or without the default Login URL set.


Thanks,

Daniel Brooks

0
0
15 Mar 2019

Hi Daniel,

Didn't understand your use case, the Login default URL applies for web apps (not mobile apps). In a web app after the login the browser will be redirected to the Login default URL (if defined). Usually for SP-initiated login no need to define it for the most use cases. For IdP mobile, the app it-self which includes the SAMLLogin WB is the responsible to redirect the user to the desired screen after receive the event LoginSuccess.

For that screenshot above, using the latest version of both components, the action InAppBrowserOnLoadStart inside SamlLogin WB should be triggered and close automatically the InApp browser.


Regards

1
0
18 Mar 2019
Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.