I have setup an Application that's is using OKTA as IDP. The app is SAML Based.This part is working fine.
But I am unable to log out. For this we have
1. Enabled Single Logout
2. Set the Single Log out URL (I received this from Metadata of IDP under header Identity Provider Single Logout URL)
3.Sp Issues (I received this from Metadata of IDP under header Identity Provider Issuer )
4. Signature Certificate (This is the certificate of IDP)
Now when I call the Logout URL I am receiving 403. On checking the Logs of OKTA I see the (User Single Sign out from App Failure:- Malformed Request)
Can any one please help me how to fix it.
I am assuming that I just need to call the logout URL and the session will kill off. Is my understanding correct?
Reviving a very old thread, check that you have a ?ReturnTo=<path> at the end of the logout URL.
Okta requires strictly post binding requests for logout. Please make sure you are making POST requests for logout and you are using correct entity Id in request.
I think the setting values below need to be set for sp side.
Set the Single Log out URL
Sp Issues
Signature Certificate
It is not on idp side.
Related
I want to implement SSO SAML2 with wso2 ei in React where
I go to check if I am authenticated or not
If not authenticated I should redirect to sso URL
When I sign in successfully on sso identity provider, I redirect to my react app with token
Then save token to localstorage and go ahead
I have tried it with Passport and Express where rendering is happening on server side. But I want it on the client side with React, steps:
I go to my home page and click on login page
It take me to wso2 identity provider and then I login
Then I redirect to my express app
The short answer: you can't do that.
You cannot use SAML without a backend. SAML requires you to register a Sercice Provider (SP), which must be identifiable with an SSL cerificate. Therefore the SP must have a private key, which you cannot distribute to a browser client for obvious reasons. On top of that, the assertion endpoint should accept a POST HTTP request, which traditionally only a server can do.
You can skip the IdP discovery if you know which IdP you wish to use, but the assertion phase cannot be circumvented. You must have an assertion endpoint for the SSO. This endpoint must be able to decrypt messages encrypted with the public key of the SP, so it must be implemented on a server.
To get as close to what you want as possible, you can implement the SP as a separate microservice that only has one (or two if you're utilizing the DS) endpoint(s). The assertion endpoint of your login service can create a token for the user and redirect them to the frontend carrying the token in a query variable.
Using IdentityServer3, Kentor.AuthServices 0.19 (with OWIN middleware) and a standard MVC 4 WebApi 2 app, we have followed instructions at https://github.com/KentorIT/authservices/blob/master/doc/IdentityServer3Okta.md
and it appeared that we achieved successful IDP-initiated login.
However, when we looked closely at this, and using KentorStubIdp (where we first noticed we were prompted to provide a SAML response), we found the following
IDP hits our endpoint, e.g. identityserver/okta/acs, status 303
Successful redirection to our redirection endpoint in our app, which is coded to return a redirection to the identityserver authorisation endpoint, thus
var client = new AuthorizeRequest(new Uri(identityServerUrl + "connect/authorize"));
var returnUrlForIdp = client.CreateAuthorizeUrl(
"{client_identifier}",
"id_token token",
scopesForAuth,
hostUrl,
state,
nonce,
acrValues: string.Format("idp:{0}", idp),
responseMode: "form_post"
);
return Redirect(returnUrlForIdp);
This results in a 302 to identityserver/connect/authorise. It appears that this has all the login information it needs, and I would have expected a 200 straight into the app, but instead we get a 302 to identityserver/login?signin=xxx which gives a 401 which appears to trigger...
The subsequent call to the login endpoint gets a 303 redirection back to the IDP, which marks the start of an ultimately successful SP-initiated login. Meaning it comes back to identityserver/okta/acs, then the /callback endpoint, then /connect/authorise then the user is logged in.
I cannot find any meaningful difference between the first and second calls to /connect/authorise except
The successful attempt is preceeded by a call to identityserver/callback
Cookies for idsvr and idsvr.session appear not to be set on the first call but are in the second
Also, Kentor config settings seem to be in order - e.g.
AllowUnsolicitedAuthnResponse = true
and
AuthenticationMode = Microsoft.Owin.Security.AuthenticationMode.Passive although this last one didn't seem to have an effect either way
At this point I'm just trying to work out a) whether this is how it is supposed to work under the covers and b) if not, where should I focus my attention to diagnose the problem.
Is there a particular set of circustances that trigger authservices to initiate an SP-initiated SAML request if a, IDP-initiated one is lacking info?
Any advice much appreciated.
Using Idp-initiated sign on with SAML2 + OIDC is a bit tricky, as OIDC doesn't support it. Which means that IdSrv3 is not really built for that scenario either.
The outline of what you would need is:
Idp sends unsolicited response to IdSrv3/AuthServices.
AuthServices validates response
IdSrv3 establishes log in session on IdSrv3.
User is redirected to client application's login init url
Client app initiates a OIDC sig in towards IdSrv3.
IdSrv3 Single signs on with session established in 3.
User is redirect back to client app.
Looks like step 2 works, but step 3 is not properly done. Which means that in step 6 there is no session, so user is redirected all the way to the Idp to pick up existing session. This works, but is somewhat ugly. And if you later on want to do single sign out there is a session count mismatch which might cause issues.
We have a successful implementation of SSO with Okta as the IdP and an external PHP site as a SP. We are currently utilizing the Okta Sign On Widget which sends our PHP SP a SAML2 Token.
Question is, can we now change from the widget to the API and still get the SAML 2 token on successful login via the API?
So, Since posting this I figured out that - 'yes you can'. I don't know if this is the cleanest/best way but it works and here is how to do it in case anyone else gets stuck looking into this issue...
Already having SAML2 communication working between Okta as IdP and
PHP site as SP.
Create an API access token in Okta.
Use the access token to post a request for a one-time use token from
the API for a specific user you want to login as:
http://developer.okta.com/docs/api/resources/sessions.html
Redirect the user with the retrieved one-time session token to your
App's embed link with the one-time session token:
http://developer.okta.com/docs/examples/session_cookie.html#retrieving-a-session-cookie-by-visiting-an-application-embed-link
This will log the user into Okta to get a proper session we can then
use to send to our PHP end-point to get the SAML2 token we want but
while utilizing the full customization benefits of the API.
I am implementing the Azure B2C preview in our mobile app but I am having trouble retrieving the application claims once the Signup policy has completed and the redirect_uri is called. I have specified the claims I need returned through the "Application claims" section of the policy blade and similarly through the other two policies (Sign-in and Profile) but I never receive a JWT along with the access code on the callback to the redirect_uri.
I have also tried HTTP and HTTPS in the redirect_uri and using the different response_mode settings but all i get is the code returned.
Am i missing something, or does the signup policy not support returning other claims at this point. I was planning on using them to send a welcome email to the new user.
I think i may have just realised - i need to make a call to the token endpoint to swap my code for the id_token and then i can get the claims.
So I am trying to setup Okta as an identity provider, and I want to login to an application using the Service Provider initiated workflow. I've setup the template SAML 2.0 application in Okta and setup the entry point and SAML certificate on the Service provider. The Service Provider initiates the workflow just fine, a popup opens with the Okta login dialogue. But once the login is complete I am taken into the Okta portal with a list of my apps. What should be happening is a re-direct back to the Service Provider so that it can use the userID to login the user there.
I followed the instruction here for setting up the IdP https://support.okta.com/entries/23364161-Configuring-Okta-Template-SAML-2-0-application
Here is what my config in Okta looks like
Application Label: App Name
Force Authentication: no
Name ID format: EmailAddress
Recipient: https://serviceprovider.com/_saml/validate/okta/
Audience Restriction: https://serviceprovider.com/
authnContextClassRef: Password Protected Transport
Destination: https://serviceprovider.com/_saml/validate/okta/
Response: signed
Assertion: signed
Request: uncompressed
Default Relay State: Leave blank since we are only doing SP initiated workflow
Post Back URL: https://serviceprovider.com/_saml/validate/okta/
Attribute Statements: none
Group Name: leave blank
Group filter: leave blank
I don't see any errors in the Okta portal or in the Okta administration panel, so I can't figure out why it is not completing the workflow and re-directing back to the SP.
Is there a place in Okta to see any errors that might be getting thrown by the process?
Anyone know what might be up?
I had a similar problem a while back. In my case, the "Rquest" was set to "compressed". changing it to "uncompressed" solved the issue. But in your case I see it is already "uncompressed"...
However, try to contact OKTA's support - they can help you out.
The answer is different depending on the type of SAML HTTP BINDING used for the SAML Authentication Request.
For HTTP Redirect Bindings you need to set the Okta Request to "compressed".
For HTTP POST Bindings you need to set the Okta Request to "uncompressed".