I am trying to setup SAML using SP initiated sign on in OKTA (IdP) using my Windows Application (SP) however i get a 400 bad SAML request after IDP authentication of my credentials. Instead of redirecting back to the application URL (SP) i get a 400 Bad SAML request.
My SP URL - https://sampleapp.company.com/appname/default.aspx
My SAML ACS URL - https://sampleapp.company.com/appname/SAML/authenticate.aspx
ON the SP side i have added the Idp connector URL and the certificate key (no trailing spaces) to the web.config.
On the OKTA configuration I have added the SAML ACS url in all the 4 sections
1) Single sign on URL
2) Recipient URL
3) Destination URL
4) Audience URI (SP Entity ID)
Name ID format is - Unspecified.
I dont see the 'Compression' menu on the configuration page. Rest of the advanced settings are kept with their default values.
I have tried playing around with the Default Relay State section as well but no use.
I hit the SP -> redirect to OKTA page -> Enter credentials -> 400 Bad SAML request.
Hit the Home button -> Hit the application chicklet -> Log into the application succesfully (this is Idp initiated) which works fine.
I have tried all the links and suggestions on the OKTA forum but cant get past this 400 bad SAML request. Is there something incorrectly set up in the OKTA configuration?
Any help would be appreciated :)
Thanks
The "Single Sign-on URL" should be the SAML ACS URL.
The Audience URI must be the entity ID of the SP, which is usually not the ACS URL.
As far as I can tell, the Recipient URL doesn't make a difference for SP-initiated flow, but I couldn't find any documentation about it.
Related
I try to integrate my Python app(backend client) into the Keycloak system using openid connect, why do I have to fill the Valid Redirect URIs field? From my understanding for OAuth 2.0, the backend channel just need to exchange the code for id and access tokens in the Authorization Code Flow process
Why do we need a redirect URL here, shouldn't it only filled in the front end client?
Any Ideas?
We need it to restrict to what URL we are allowed to redirect to after a successful login. We do this to improve the security for your users, because it would be a big security problem if the provider could redirect to any URL after login.
The client which receives the authorization code and the one which exchanges the code for tokens must be the same client - at least from the Authorization Server's point of view. Theoretically you can have separate applications which handle parts of the OAuth flow, but they must be using the same client ID.
Ideally, the redirect URI points to an endpoint exposed by your Python backend. After Keycloak (or any Authorization Server) finishes authentication and authorization, it will redirect the user to that endpoint together with the authorization code. This way the authorization code will go straight to the backend client, the frontend app will never have to handle it. By registering the URL you want to make sure that no one performs authorization using your client ID, but asks to send the code to another application.
I am implementing service provider-initiated SSO for Salesforce where the service provider will be Salesforce and the identity provider will be a lambda code. The lambda code will allow a user after verifying the user's mobile number. Once the mobile number is verified a SAMLResponse will be sent by lambda.
I have configured SSO on Salesforce as below:-
I am also able to generate a valid SAML response and have validated it on Salesforce SAML validator as below:-
I have created a login page that will be redirected from Salesforce.
I have also created an API to get a unique SAML response every time for the given federation ID as below:-
https://qodz4saz9a.execute-api.us-west-2.amazonaws.com/v1/generate-saml-response?FederationID=rahul#xyz.com
URL for Salesforce login page is- https://im--partial.my.salesforce.com/.
After all this setup I am able to get redirected to the login page I have created from Salesforce by selecting "Log In with a Different Account" option and then selecting "Twilio" as below:-
Salesforce is redirecting to the login page with a SAMLRequest parameter in the URL as below:-
http://salesforce-sso-page.s3-website-us-west-2.amazonaws.com/?SAMLRequest=fZJRc6IwFIX%2FC.....
I am not sure how to proceed from here and allow login to Salesforce from my login page. Once the user enters a mobile no and OTP, I am redirecting the user to below URL -
https://im--partial.my.salesforce.com?SAMLResponse=PD94bWwgdmVyc2lvbj0i.....
Here I am using SAMLResponse as a query parameter to pass the base 64 encoded SAML response for login to Salesforce. But I am not sure if it is a correct way to authenticate and login to Salesforce.
After entering the OTP(test OTP is 1234) I am getting the below error.
I am not at all using the SAMLRequest generated by Salesforce for generating the SAMLResponse for now.
I have gone through many documents but couldn't find a way to pass the SAMLResponse to Salesforce for login. Please let me know if anybody has any idea about it or if I am following the wrong steps.
The SAML response is sent to the service provider in a specific "way", the protocol refers to this as a binding. In this case the expected binding is HTTP POST. With HTTP POST as your binding, the SAML response must be submitted in a body of HTTP request sent to the service provider via a POST method. The Login URL listed in the Single Sign-On Settings screen is the endpoint where the SAML response should be POSTed. It might look something like this:
POST / HTTP/1.1
Host: im--partial.my.salesforce.com
Content-Type: application/x-www-form-urlencoded
Content-Length: nnn
SAMLResponse=response
Do you need to worry about the SAML request? It depends on your workflow and desired end-user experience. The considerations that go into this decision deserve their own SO question. Meanwhile, take a look at SAML Technical Overview for a summary of these workflows.
Last but not least, this whole sequence of authentication via your mobile number is supported by Salesforce out of the box on some Salesforce products.
I am working on SP initiated saml sso and it is completely new to me. I have gone through lots of articles and videos(wikipedia, centrify chalktalk, medium posts) but i am not able to understand some of the things:
Is the saml assertion the SAML token? if not, then how is it generated?
Suppose i have a saml based IdP and two saml enabled SP. Now in a purely post binding, when i login to one of the SP and then login to the second SP, How does the second SP log me in? To be more precise, how does the second SP know that the user is already logged into first SP? What is that parameter(s) that decides it? (can i get more low level explanation on this).
Does the IdP store data in cookie about the session or is there something else that i am missing out.
If there are any articles based on this please do post them.
Thank You.
Let me first answer your specific question points:
1) Is the saml assertion the SAML token? if not, then how is it
generated?
-This is all just terminology for the same thing. A SAML Assertion and a SAML Token are the same thing. There are 2 different SAML assertions/tokens that are important for you to focus on. The SAML Request and the SAML Response. The SAML Request is what is sent from the SP to the IDP in SP initiated SAML SSO. The SAML Response is what is sent from the IDP to the SP as the final part of SP initiated or during IDP initiated SAML SSO. SP initiated is when the user starts at the SP app, is redirected to the IDP for authentication, and then sent back to the SP app by the IDP. IDP inititated is when the user starts at the IDP, and goes right to the SP. A SAML Assertion is just XML that has been signed, converted to a string and base 64 encoded. they are redirected with the user from SP to IDP and back.
2) Suppose i have a saml based IdP and two saml enabled SP. Now in a
purely post binding, when i login to one of the SP and then login to
the second SP, How does the second SP log me in? To be more precise,
how does the second SP know that the user is already logged into first
SP? What is that parameter(s) that decides it? (can i get more low
level explanation on this). Does the IdP store data in cookie about
the session or is there something else that i am missing out.
-This is specific to your IDP. As a Centrify SME, I can tell you how Centrify and similar IDPs work. When a user signs into the IDP, whether its from an SP initiated redirect, IWA on their corporate machine, or directly to the IDP itself, a cookie is added to the browser. In the case of Centrify, this cookie is called .ASPXAUTH. Every time a user is taken to the IDP after logging in, they are not prompted to log in again. So if a user starts at SP1, gets redirected to the IDP, logs in, and is redirected back, the cookie has been set by the IDP. Now if they go to SP2, by default that SP would also redirect to the IDP, but the IDP would not prompt for auth again because of the set cookie. So the user wouldn't notice the redirect and the IDP would just send them right back to SP2 with the appropriate SMAL response. So Like this:
SP1 > SAML Request and redirect to IDP > Log in to IDP and cookie is set> SAML Response and redirect back to SP1 > Navigate to SP 2 > SAML Request and redirect to IDP > Cookie is set so immediately redirect back to SP with SAML Response.
Centrify also has API's that can be used by SP's. For example, an SP could do a client side API call to /security/whoami to see if there is a valid ASPXAUTH cookie in place. So SP2 could check for a valid cookie and decide to to redirect at all because the cookie has already been set. https://developer.centrify.com/reference-link/securitywhoami
Hopefully this helps. I wrote a very basic example of this in c# while at Centrify. You can find the code here https://github.com/centrify/CentrifySAMLSDK_CS. Feel free to reach out here with more questions or find me on twitter https://twitter.com/NickCGamb
Yes, the Assertion is normally a fully portable token by itself, but there are ways to bind it to for example keys on the requester.
The second SP does now that the user is already signed in. The SP will redirect the user to the IDP with an authentication request to the IDP. IDP usually saves a cookie for the user when it authenticated the first time, this is not specified by SAML but generally how its done. When the user arrives at the IDP the IDP looks at the cookie and if the user authentication is still valid the IDP automatically sends a valid Assertion/token to the SP. It is possible for the SP to overide this behaviour by specifying the ForceAuthn attribute in the authentication request.
As for resources I would recommend the SAML Technical Overview from OASIS http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview-2.0-cd-02.pdf
I'm trying to use the authenticationendpoint application that comes with WSO2 as the new only login entry point of an old application. For testing purposes I just did a page that redirects to thi URL
https://localhost:9443/authenticationendpoint/login.do?relyingParty=My-Issuer&sp=Test-App&sessionDataKey=14792551&authenticators=BasicAuthenticator:LOCAL
The login page appears as expected, but once I set the user and password shows this message:
Authentication Error !
Attention:
Something went wrong during the authentication process. Please try signing in again.
Seeing the output in the console on debug mode, this is what is shown
... Many of the same error saying that Authentication Context is null
[2017-01-06 15:40:08,836] DEBUG {org.wso2.carbon.identity.application.authentication.framework.util.FrameworkUtils} - Authentication Context is null
[2017-01-06 15:40:08,836] DEBUG {org.wso2.carbon.identity.application.authentication.framework.util.FrameworkUtils} - Authentication Context is null
[2017-01-06 15:40:08,836] DEBUG {org.wso2.carbon.identity.application.authentication.framework.util.FrameworkUtils} - Authentication Context is null
[2017-01-06 15:40:08,837] DEBUG {org.wso2.carbon.identity.application.authentication.framework.handler.request.impl.DefaultRequestCoordinator} - Session data key : 22451696
[2017-01-06 15:40:08,837] ERROR {org.wso2.carbon.identity.application.authentication.framework.handler.request.impl.DefaultRequestCoordinator} - Context does not exist. Probably due to invalidated cache
I thing I'm doing something wrong, maybe there are not enough parameters sent, or they are the wrong ones, the user and password are correct because I can login into the carbon itself with it, and it is also a valid user for the testing SP.
The SP config is described:
Basic Information
Service Provider Name: Test-App
Claim configuration
Use Local Claim Dialect
Subject Claim URI http://wso2.org/claims/username
Role/Permission Configuration
Permissions AdminTest
Role Mapping AdminTest->Admin
Inbound Authentication Configuration
SAML2 Web SSO Configuration
Issuer: My-Issuer
Assertion Consumer URLs: https : //localhost/Test/main.asp
Default Assertion Consumer URL: https : //localhost/Test/main.asp
NameID format: urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
Certificate alias: wso2carbon
Response Signing Algorithm: ...#rsa-sha1
Response Digest Algorithm: ...#sha1
Checked values
Enable Response Signing
Enable Single Logout
Enable Attribute Profile
Include Attributes in the Response Always
Enable IdP Initiated SSO
Enable IdP Initiated SLO
Others are in blank OAuth, OpenID, etc (let me know if that is maybe the problem, so which should be filled out.
Local and Outbound Authentication Configuration
Authentication Type: I tried with Default and Local Authentication = basic and password-reset-enforcer
This is checked:
Assert identity using mapped local subject identifier
Use tenant domain in local subject identifier
Use user store domain in local subject identifier
Request Path Authentication Configuration
basic-auth
Inbound Provisioning Configuration
SCIM Configuration
PRIMARY
Dumb Mode is not enabled
The rest is left blank
I have spent many days tracking this problem but no answers or are for older versions.
I tested with JDK 7 and 8 (latest of them) I'm working with WSO2 IS 5.2.0. Someone can lead me to a solution to use this application as the only entry point for my SPs? The idea after is to send back a SAML2 response to a page in the SP side that read the information and control the authorization part.
Thanks in advance.
You have configured for a SAML SSO scenario. Therefore your SP have to call the SAML SSO endpoint of WSO2 Identity Server with a valid SAMLRequest. That is https://hostname:port/samlsso.
AuthenticationEndpoint is just an intermediary application. SAML SSO endpoint is the one that should redirect the user to AuthenticationEndpoint after first processing the SAMLRequest. You must not call it directly.
Refer this to learn how to run a sample SAML SSO application with WSO2 IS. While running that, you can monitor the HTTP Request/Response flow using a tool like SSOTracer for Firefox and understand how the communication works.
In similar to SAML SSO flow, if you are using any other authentication protocol, you first have to call the protocol specific endpoint. E.g. If you are using OAuth2 or OpenIDConnect, then you should call /oauth2 endpoint. Never /authenticationendpoint directly.
Created a web based application which needs to integrate forms authentication and SSO. Currently forms authentication will validate all the registered users.
What I need is to integrate SSO as well in to the application. ie, If the user not authenticated then redirect to identity server (Okta) configured with WS-Fed and added the application, validate and response to landing page. Please can you help on this. Please let me know if any more information is required.
Can you please explain this statement " If the user not authenticated then redirect to identity server (Okta) configured with WS-Fed and added the application"?
Please see this link https://github.com/okta/okta-music-store. Under section "Adding Single-sign on to your Music Store" you can see how C# sdk can be used to implement single sign on.
Essentially what you need is a cookieToken from Okta. Using cookieToken as one time token and a redirect url (Can be your app url) you can use /login/sessionCookieRedirect?token=&redirectUrl=. This will create active session with Okta and redirect your user to your app or redirect uri.
Cookie token is obtained via series of two calls. Authentication that gives you session token in response. Session token is exchanged for cookie token via create session call.