I am trying to troubleshoot and understand SAML for a government citizenship authentication. I can only use SAML Tracer, Firebug or Fiddler.
There are a few steps:
1. User gets directed from website to Service Provider.
2. Service Provider creates a HTML form with partner_id and sends this to Identity Provider.
3. Identity Provider shows login page. User logins on Identity Provider with mobile SMS OTP.
4. Identity Provider authenticates and sends Assertion back to Service Provider website.
5. Service Provider displays the right webpage after authentication.
I want to tell, what exactly happens at step 2.
For step 4, I can see the Assertion in the dump. But there is a lot of garbage string before that.
At step 5. when the partner_id was not sent, there displayed webpage at step 5 will be an error message. Is there anyway I can tell this error display from the HTTP request? (I suppose this will be hard to answer.)
Related
We have a project where the client requests the use of their own Identity Provider, in this case, it is SalesForce.
We secure the application using IdentityServer 3 and have configured it that for this client (based on parameters) it will use SalesForce as the IDP.
For the web app, no problem, Identity Server redirects to the Sales Force login page and everything works great.
Now we have a mobile app to build and the client would like to avoid having a web login page and would rather have a nice polished login form built in the application. This means that we will have to use the Resource Owner flow.
Now, the users creds are on SalesForce side so how does that work and is this at all possible in IdentityServer 3 ?
I see 2 possibilities but I kind of like neither of them:
Send the auth call to IdentityServer which should detect that it is up to SalesForce to validate the user and forwards the request there. I think it is not good as I would rather avoid having my IdentityServer dealing with credentials that he should not even know
Send a first auth call to SalesForce to get some "id token" that would then allow me to send another auth call to IdentityServer which will then recognize the "id token" and release an access token.
That seems like a stretch and forces the app to know that there is an IDP which is none of its business.
Any idea?
Let's say we have a service provider app called A hosted on tomcat, a user clicks a link to the SP A. SP A sees no token is provided so it redirects the user to the IdP for authentication (with a SAML Authn request provided by some means). The IdP then redirects the user to some common login page where credentials are provided, assuming that these credentials are correct the IdP creates a SAML response with a token and some assertions about the subject, and sends it back to SP A. SP A sees this and allows the user access into the application. Great!
I have a few questions though
How is the authorisation request/response sent, I understand there is a redirect binding and a POST binding where the SAMLResponse and request are encoded either as a query param, or sent as an XHTML form in case of a POST binding. But I'm not sure which is used where?
A service provider is the thing providing a service, so Office 365 or Sales force for example. Is each one a separate service provider? I ask as I watched a video where the guy said the service provider was the thing that hosted these services, so I'm not sure of the correct answer here?
How is the token stored on the client side? So for example I am now authenticated against SP A, the user then tries to use SP B from the same machine/browser window, how does SP B and the IdP know that the user has already authenticated and therefore doesn't need to re-authenticate. I.e. the SSO aspect of it.
Does SP B need to be hosted on the same tomcat instance for this to work?
I dedicated significant time to get SSO working for me. The most helpful document was this specification
The answers below are based on this experience:
Redirect or Post binding is used depending on a respective HTTP request header. The Post binding is recommended since it does not imply restrictions on data volume transferred.
A Service Provider in this context is anything that clients request. There may be many of them, participating in the same SSO scheme.
The service providers must be SSO-aware, which includes handling of the authentication response data. Usually you don't have to implement the protocol - there are ready-made frameworks that your SP can utilize.
Service Providers may reside on different servers.
From my own experience:
You choose your own SAMLBinding (redirect or post) depending on what your idp and sp supports. This binding type will be used both for the 1st step (SP -> Idp) and 2nd step (IdP -> SP). If you have some running environment, open your browser devtools and look at network tab to see what happens. It's just a way to send data from browser to SP/IdP.
Both Office 365 and Salesforce.com are cloud services, right? Let's take Office 365. it means that beyond "end-user" services (like Word, Excel) there is some technical SSO service which are common to the platform. It can be viewed as lower (or technical) service layers, I think that what you speaker meant.
The SAML token is stored by you SP application inside your browser, either hidden inside web page, cookie or web storage. It depends on how your SP is implemented.
SAML response can be validate by each SP based on shared private key, so it will decrypt the token using this key and be able to grant user without the help of IdP redirection.
Tomcat have some extension to support SAML. But SAML is designed to work without being on the same instance, as the opposite as basic JSESSIONID cookies.
So you have several instances, of course.
I am trying to understand implementation of SSO system for service provider. Here are my questions.
User logs into System A. System A does authentication and displays a link to the user on page. When User clicks the link, System A redirects user to System B where System B is a 3rd party vendor. Who is IdP here and who is SP?
Is there any server to server communication in a flow initiated from IdP to SP? Is it required in all scenarios?
can you explain the data flow step by step in case of IdP initiated flow to SP?
Any material on this same or simple explanation will help.
In answer to your questions and assuming SSO via Security Markup Language (SAML):
System A is the Identity Provider (IdP) and System B is the Service Provider (SP).
There is no server-to-server communication. Information is passed via the client browser using HTTP bindings, for example HTTP POST.
Step by step IdP-initiated workflow (taken from OASIS SAML V2.0 Technical Overview):
If the user does not have a valid local security context at the IdP, at some point the user will be challenged to supply their credentials to the IdP site, idp.example.org.
The user provides valid credentials and a local logon security context is created for the user at the IdP.
The user selects a menu option or link on the IdP to request access to an SP web site, sp.example.com. This causes the IdP's Single Sign-On Service to be called.
The Single Sign-On Service builds a SAML assertion representing the user's logon security context. Since a POST binding is going to be used, the assertion is digitally signed before it is placed within a SAML message. The message is then placed within an HTML FORM as a hidden form control named SAMLResponse. (If the convention for identifying a specific application resource at the SP is supported at the IdP and SP, the resource URL at the SP is also encoded into the form using a hidden form control named RelayState.) The Single Sign-On Service sends the HTML form back to the browser in the HTTP response. For ease-of-use purposes, the HTML FORM typically will contain script code that will automatically post the form to the destination site.
The browser, due either to a user action or execution of an “auto-submit” script, issues an HTTP POST request to send the form to the SP's Assertion Consumer Service. The service provider's Assertion Consumer Service obtains the message from the HTML FORM for processing. The digital signature on the SAML assertion must first be validated and then the assertion contents are processed in order to create a local logon security context for the user at the SP. Once this completes, the SP retrieves the RelayState data (if any) to determine the desired application resource URL and sends an HTTP redirect response to the browser directing it to access the requested resource (not shown).
An access check is made to establish whether the user has the correct authorization to access the resource. If the access check passes, the resource is then returned to the browser.
We want an external identity provider within our identityserver where user is redirected to login to this external identity provider (Idp) and complete the authentication there. The external Idp redirects the response back to our identityserver where we want to form the user claims from the response and redirect back to the calling client.
We followed the answer to this stackoverflow question. We implemented our own owin middleware following the the Anders Abel Tutorial and owin middleware's for Google Auth as external Idp.
We also followed the exact implementation of CustomHrd Sample. Everything in the middleware works perfectly, the user gets redirected to the external Idp with the state, we get the response from there back (with the state), we form the claims and on completion we finish the owin middleware pipeline and redirect to /core/callback, but the Identityserver gives the following error:
The URL call flow is available below:
/core/connect/authorize?params
/core/login?signin=3a84a4f3dfe3218b06f3aa2185415e1e
/core/ta (IDP Selector page)
/core/login?signin=3a84a4f3dfe3218b06f3aa2185415e1e (Resume Uri after Idp Selection)
/core/ta/tacall?state=
Redirect to External URL with state
Callback from External Identity provider with state: /core/ta/tacall?state=
Redirect from middleware to redirectUri after forming claims - /core/callback
Error occurs on /core/callback saying "There is an error determining which application you are signing into. Return to the application and try again."
Can you please help us figure out why would this occur?
Note: I also looked into the cookies, we are passing the cookie to /core/callback which contains the SignInMessage.
I'm new to the Oauth2 autentication process and i'm a bit stuck cause i would like to use Zend Framework OAuth module to connect to Box.com API.
I've found an example to connect to an Oauth service with zend framework and i've followed some tutorial on youtube about the oauth service, and for what i've understood i've at first to connect to the authorization process (with the client_id the response url and the response_type set to "code"). That's what i've learned from the tutorial. But in the developer part of the www.box.com site there is a strange parameter to make the GET call and try to authorize the application to access the user content:
https://www.box.com/api/oauth2/authorize?response_type=code&client_id=YOUR_CLIENT_ID&redirect_uri=YOUR_REDIRECT_URI&state=security_token%3DKnhMJatFipTAnM0nHlZA
The parameter "state" has to be updated with information on the application or it has to be left as it is in the online tutorial? I'm a bit confused.
The state parameter is optional. It is intended to provide an additional layer of security for your application.
Consider the OAuth workflow:
Your application redirects the user to Box.com
Box prompts the user for credentials and authorization
Box redirects the user back to your application with authorization information in tow.
The state that you send to Box in Step 1 is sent back unchanged to your application by Box in Step 3. Your application can compare these values to verify that the Box redirect in step 3 originated from a request made by your application.
The state can be any arbitrary string. Pick a random string of some length. This value should be generated new for each new OAuth request (i.e., Step 1), since it's intended to identify a single OAuth cycle for a particular user.
Does that make sense?