I am trying to add a new service to an existing Okta setup. The service relies on SAML for authentication and uses strict checking of SAML messages.
When Okta session state is already present in the browser, everything works fine. Okta SAML response contains all the necessary attributes to get verified and everything just works.
However, when using a "clean" browser to initiate a new session, my service can not properly validate the Okta SAML response. The response is valid and properly signed, but is missing the InResponseTo attribute which is required for strict verification.
I wonder if somebody may have encountered an issue like that before? May there be some hidden setting in Okta or some common setup mistake in the authentication provider?
Your service is complaining about the sequence of steps you use to initiate the SSO flow. In a so-called service provider-initiated SSO flow, you click on a link that goes to your service. Your service acting as a SAML service provider (SP) then sends a SAML authentication request to the identity provider (Okta) which then responds to this request with a SAML response. Since the identity provider is responding to the request from a service provider, the SAML response will contain an InResponseTo element.
How do you fix this? This is all about your service rather than Okta. You need to determine the correct URL and/or format of the request to your service that will cause it to fire a SAML authentication request to the identity provider.
See Okta docs for more info
Related
I am using keycloak as IDP, jersey rest services as backend and angular UI as frontend where my backend and frontend are separate application running on the same tomcat server.
Every example I found on the internet uses complete backend for SP initiated SAML SSO. I don't understand where does frontend contribute or how is frontend protected.
As when we talk about open id SSO protocol I found out that user agent calls frontend application which redirects user to IDP and gets the code and passes it on to backend. Backend does all the validation of the tokens.
So I had some questions
Is the flow in SAML same as open id if we have a frontend application?
Can frontend application produce SAML request and redirect user to the IDP?
After successful authentication IDP redirects to backend or to frontend?
How are services protected and where is the SAML assertion validated?
Is the flow in SAML same as open id if we have a frontend application?
more or less. User goes to front end application, is denied access as they don't have a valid session with the application.
Can frontend application produce SAML request and redirect user to the IDP?
yes. It would need to create a SAMLRequest containing an AuthNRequest and POST it to the SP.
After successful authentication IDP redirects to backend or to
frontend?
more or less. The IdP checks the SP Attribute Consumer Service (ACS) url in the metadata first. If it doesn't match, it refuses to send the SAMLResponse to the SP.
How are services protected and where is the SAML assertion validated?
It's up to the SP. If the user doesn't have a valid session at the application, they need to be redirected to the IdP and the application must validate the SAMLResponse and create a valid session for the user based on the attributes in that response.
Validation is done via X509 certificates contained in SAML metadata. It's complex stuff though.
I have a web app developed using Create-react-app
I host it on IIS, the IIS only response to load the app, there is no server side logic on it (no Express or any other web server)
The app is using a RESTful API on the same IIS, it is out of my control (I cannot make change).
Now one of my client request to add SAML SSO to our app.
I would like to know:
in normal situation, which one is the Service Provider? My IIS Web server? or the API service?
For my case, I cannot implement SAML to API service, my web service only used to load my app without server side logic, how can I implement SAML?
Could any one give me some React implement SAML SSO tutorial or article for reference?
Thanks for any help, any information or suggestion are welcome!
in normal situation, which one is the Service Provider? My IIS Web server? or the API service?
I assume the client wants to authenticate the users using their internal IdP. So your application is the SP. But you will have to define different token service (details below).
With SPA (a single-page-applications) I see the problem, in SAML the user is redirected or posted away from the SAML request and SAML response.
I have a login page to enter id/pw, post them to API server Login endpoint to authenticate and get back a JWT token. After that we use that token in API calls for authentication
The API services are using a JWT token issued based on the provided username/password. I'd recommend to extend the token service (or use a different service) to issue a JWT token based on the provided SAML response - a token swap service. In many OAuth implementations it's called SAML grant type.
I cannot implement SAML to API service, my web service only used to load my app without server side logic, how can I implement SAML?
Usually after the authentication the user is redirected or posted to the SAML ACS endpoint URL, where the server can create sort of session (cookie, parameters, token, ..) and the user is redirected to a URL returned the web page with the session information.
If you are using an SPA, you could use a popup window or SAML with redirect (not with post), where the page could read the SAML response parameters (assertion, signature, ..) and use them in the token swap service mentioned above.
When processing the SAML response, try to use some mature, known, out-of-box libraries, it's a security service and not doing it properly may cause security weaknesses. But you need to do that on the server side, as at the end you need the JWT token consumed by the APIs.
I am trying to configure salesforce as idp for my saml2.0 based sp. I have enabled domain, sso, created connected app with appropriate profile. with all this I am able to login into sp using using idp initiated url. idp initiated salesforce url correctly, my sp gets correct saml response. but when I try to use sp initiated flow and post saml request to salesforce endpoint, it give error "Insufficient Privileges". Have anyone faced this issue or knows something about this?
I was able to solve this issue. Apparently salesforce doesn't give what is the error. Here I was using redirect request sending to post url.
Scenario:
Browser(User) requests resource from Service Provider (SP).
SP Redirects (with SAML Request) to Identity Provider (IdP).
Since it is first login, User gives the (IdP) his/her valid credentials.
IdP then redirects Browser (with SAML Response which includes SAML token) to the SP page.
Application has a link to different application. The Second application needs to validate the user credentials with the same IdP.
User clicks on that link and browser opens the second application. Browser contains the same SAML response from SP.
In Step 5 how can I authenticate the user with SAML response and allow the user to be logged in automatically.
Do I need another SP?
I will not be able to use the SP from step 1 as it is external application.
Appreciate your help
If the second application is in a different administrative domain, it should be done through its own SAML SP starting another SAML request/response exchange with the IDP. If it is in the same domain you may be able to pass an intra-domain credential such as a cookie between the first application and the second (or rely on full SAML as well). You would never reuse the same SAML response because that is meant to be one-time use only.
This is the 1st time I am working in SSO with SAML.And we are going to use the HTTP Post method and the IDP is salesforce. I got below Steps from net.
User accesses a custom application for the first time
Service Provider Security Filter checks if the security context is available
and redirects the user to IDP with a SAML SSO request
IDP challenges the user with the authentication dialog and redirects the user to
Request Assertion Consumer Service (RACS) after the user has authenticated
RACS validates the response from IDP, establishes a security context and redirects the user
to the original application endpoint
Service Provider Security Filter enforces that a valid security context is available and lets the user access the custom application.
Here my Question is IDP needs to authenticate application endpoint. Here the SAML plays between common web page to IDP to initiate SAML request/response. Then how the IDP connect to endpoint? Is that follow any other language to connect and authenticate endpoint? else how it connects? Could you please someone explain the concept?
During configuration of SAML at your Identity Provider, you define an AssertionConsumer endpoint, which is an URL at your application where you expect to receive response from the IDP. After authentication, IDP connects to this endpoint by sending a SAML Response message to it. IDP typically authenticates to the endpoint by digitally signing the SAML message, which you then verify for validity and trust.
The ways of sending SAML messages between IDP and SP (= connecting IDP to the endpoint) are called bindings. Bindings define how exactly to use existing protocols (such as HTTP) to deliver SAML messages, i.e. it tells what parameters should be sent, which HTTP method should be used... Bindings are part of the SAML 2.0 standard and you can find details on how they function in the SAML 2.0 specification.
The IDP does not directly communicate with the original URL within your application (i.e. the "original application endpoint"). The process of sending user to the correct destination after successful verification of the SAML Response (received at the Assertion Consumer endpoint) can be fully determined by you. For example, in case Assertion Consumer endpoint and the "original application endpoint" are part of the same application and share the security context, you can simply send an HTTP redirect, without need for SAML in this "last mile".