Hi,I am a developer in my team tasked with implementing SAML 2.0 web sso with one of our Service Providers(SP).This will be an IDP initiated sso flow.
Internal users log into our portal using their AD credentials and that user should be able to view our customer details(Our customer) on the SP web site by passing customer’s username.
So we have to include the customer username(This is stored in a sql database) in the claims section when we send the SAML 2.0 response to the SP.
We use ADFS 3.0(Windows server 2012 R2) for creating the SAML 2.0 response.
The way I am envisioning this is to create a Web API (asp.net 4.6.1) and capture the SAML authentication request from SP, build the claim information and use the following line of code from your API
SAMLIdentityProvider.InitiateSSO(); → For sending the SAML response to the SP
SAMLIdentityProvider.ReceiveSSO(
Request,
out partnerSP); —> For receving the SAML auth request from the service provider
These are the questions I have
1.Where does your API sit? Does it sit between our app and ADFS 3.0 and pass that request from our app to ADFS 3.0 ? Does the API interact with ADFS 3.0 to create the SAML 2.0 Response to send it out to SP?
2.I have to get the claim info from a sql server database when the SAML auth request comes from the service provider.I know I can create a custom rule in ADFS by passing in this username and define a sql query there to get the claim info.Is there an option in your API to include the username and the api passes that parameter to ADFS 3.0?
3.I fI buy your product(SAML 2.0 for ASP.NET) , all I have to pay is $499.00 and we can deploy this all Dev,QA,UAT, and Prod with no extra $? Also, there is no per user charge once this goes to prod?
Can you please address these when you get a chance , that way I can get with my manager
Thanks
Rennish Joseph
Hi Rennish
Is there a reason for including ADFS in the flow?
If the user is already authenticated in your portal application (ie the IdP) and they click a link to the external SP, you could simply lookup the customer username (ie perform an SQL query) and include this when you call SAMLIdentityProvider.InitiateSSO. There’s no need to call ADFS.
The SAMLIdentityProvider.ReceiveSSO is for SP-initiated SSO.
To support IdP-initiated SSO, the only API call you need is SAMLIdentityProvider.InitiateSSO.
If you wished to include ADFS in this flow for some reason, your portal application would need to act as a SP to ADFS, receive the SAML assertion from ADFS, and then act as an IdP to the external SP and send a SAML assertion.
You would call SAMLServiceProvider.InitiateSSO and SAMLServiceProvider.ReceiveSSO to initiate SSO to ADFS and receive the SAML assertion.
You would then call SAMLIdentityProvider.InitiateSSO to send a SAML assertion to the external SP.
However, it would seem simpler to not include ADFS.
Our licensing model is per developer. If there’s only one developer using the product all you need is a single developer license.
The runtime (ie SAML2 DLL) is royalty free meaning you can deploy it along with your application to as many servers as you wish.
There are no end-user related charges either.
Is there a reason for including ADFS in the flow?
If the user is already authenticated in your portal application (ie the IdP) and they click a link to the external SP, you could simply lookup the customer username (ie perform an SQL query) and include this when you call SAMLIdentityProvider.InitiateSSO. There's no need to call ADFS.
The SAMLIdentityProvider.ReceiveSSO is for SP-initiated SSO.
To support IdP-initiated SSO, the only API call you need is SAMLIdentityProvider.InitiateSSO.
If you wished to include ADFS in this flow for some reason, your portal application would need to act as a SP to ADFS, receive the SAML assertion from ADFS, and then act as an IdP to the external SP and send a SAML assertion.
You would call SAMLServiceProvider.InitiateSSO and SAMLServiceProvider.ReceiveSSO to initiate SSO to ADFS and receive the SAML assertion.
You would then call SAMLIdentityProvider.InitiateSSO to send a SAML assertion to the external SP.
However, it would seem simpler to not include ADFS.
Our licensing model is per developer. If there's only one developer using the product all you need is a single developer license.
The runtime (ie SAML2 DLL) is royalty free meaning you can deploy it along with your application to as many servers as you wish.
There are no end-user related charges either.
The reason I thought I have to include ADFS was in your api doc (section 10.4) ADFS inter operability, it says The web and mvc example identity and service providers demonstrate sso with ADFS.So there is no dependency on ADFS to generate SAML 2.0 Response?. Without ADFS,I just call the SAMLIdentityProvider.InitiateSSO? Will this post the SAML response to the destination url(SP endpoint)? .I want to return this SAML response to the browser that post the SAML Request.Can I get the generated SAML and return to the caller from my API rather than you sending that to the SP endpoint? Also in the SAML response ,how are you populating the InResponseTo attribute of the element? I had the same question posted on StackOverflow
Section 10.4 of our Developer Guide describes SSO with ADFS.
However, there is no dependency on ADFS. You can use our product with or without ADFS etc.
SAMLIdentityProvider.InitiateSSO will construct and post a SAML response to the SP’s assertion consumer service URL.
SAMLIdentityProvider.InitiateSSO supports IdP-initiated SSO.
If a logged in user clicks a link in your portal application to SSO to a 3rd party service provider application, this is IdP-initiated SSO.
The other flow is SP-initiated SSO where the user starts at the SP site.
If I understand your requirements, you wish to support IdP-initiated SSO.
For IdP-initiated SSO, the InResponseTo field is not included.
For SP-initiated SSO, the InResponseTo field is set to the ID of the corresponding SAML authn request received from the SP.
This is handled automatically by our high-level API.
If you wish to send a SAML response through your API you will need to revert to the SAML low-level API which gives you access to the SAML messages etc.
However, I’m not sure how this would work and, if it did, it would be a more complicated solution.
Remember that all SAML message flows are via the browser. The SAML response is returned to the browser which then posts it to the SP.
However, there is no dependency on ADFS. You can use our product with or without ADFS etc.
SAMLIdentityProvider.InitiateSSO will construct and post a SAML response to the SP's assertion consumer service URL.
SAMLIdentityProvider.InitiateSSO supports IdP-initiated SSO.
If a logged in user clicks a link in your portal application to SSO to a 3rd party service provider application, this is IdP-initiated SSO.
The other flow is SP-initiated SSO where the user starts at the SP site.
If I understand your requirements, you wish to support IdP-initiated SSO.
For IdP-initiated SSO, the InResponseTo field is not included.
For SP-initiated SSO, the InResponseTo field is set to the ID of the corresponding SAML authn request received from the SP.
This is handled automatically by our high-level API.
If you wish to send a SAML response through your API you will need to revert to the SAML low-level API which gives you access to the SAML messages etc.
However, I'm not sure how this would work and, if it did, it would be a more complicated solution.
Remember that all SAML message flows are via the browser. The SAML response is returned to the browser which then posts it to the SP.
Using the SAML high-level API, you won’t have access to the raw SAML response and SAML assertion received from ADFS.
These should not be re-used so this shouldn’t be an issue.
Instead, when you call SAMLServiceProvider.ReceiveSSO you receive the relevant user identity information (ie SAML Name ID and attributes).
You then pass these into SAMLIdentityProvider.InitiateSSO to be included in the new SAML assertion sent to the external SP.
The above is assuming you are using ADFS and your application is acting as both the SP and IdP as I described earlier.
All SAML messages are sent within the existing browser session.
These should not be re-used so this shouldn't be an issue.
Instead, when you call SAMLServiceProvider.ReceiveSSO you receive the relevant user identity information (ie SAML Name ID and attributes).
You then pass these into SAMLIdentityProvider.InitiateSSO to be included in the new SAML assertion sent to the external SP.
The above is assuming you are using ADFS and your application is acting as both the SP and IdP as I described earlier.
All SAML messages are sent within the existing browser session.
Thanks.I am not including ADFS to make it more complicated
Your welcome and understood.