We have a web app that currenlty uses membership provider against SQL Server for authentication.
100% of various clients use an existing SignIn.aspx; redirected from web.config / authentication login url.
A new client wants us to implement SP Initiated SSO to their IDP.
I recently invested time in understanding the CS ExampleServiceProvider and ExampleIdentitiyProvider; which I now feel like I understand.
Now I’m fuzzy on how to implement for this one client into our existing login.url
Initially I had thought about creating a dedicated SSO SignIn page for this one client, but because my web.config redirects everyone to the broader Signin page - I’m not sure how to insert this dedicated SignIn page into my existing project?
Any thoughts or suggestions on best practice would greatly be appreciated.
Thx in advance!
A single login page is probably the best approach.
You need a way to identify users associated with this client.
There are different ways to do this.
For example, you could use different URLs (eg sub-domain names or query string parameters).
There’s also the option of displaying some sort of SSO button on the login page and getting the user to make the choice.
Once you have a mechanism for identifying where the user is from, your login page code should check if the user is associated with this client and, if so, initiate SSO to that IdP.
If the user isn’t then display the standard login page.
You need a way to identify users associated with this client.
There are different ways to do this.
For example, you could use different URLs (eg sub-domain names or query string parameters).
There's also the option of displaying some sort of SSO button on the login page and getting the user to make the choice.
Once you have a mechanism for identifying where the user is from, your login page code should check if the user is associated with this client and, if so, initiate SSO to that IdP.
If the user isn't then display the standard login page.
Appreciate the quick reply.
(bit of a novice, see if the below makes sense)
Normal users hit serviceprovider.com
Web.config redirects them to serviceprovider.com/SignIn.aspx
Working from the component space example.I don’t want to modify the way my current page looks cosmetically serviceprovider.com/SignIn.aspx (don't want to add a qualify box for them to fill out)
I anticipated these new SSO users hitting serviceprovider.com/newClientSSOSignIn.aspx (This page would have a link for them to sign into their IDP if not signed in already)
Though my web.config in it’s current state won’t let me hit the above, it just redirects me to the broader SignIn.aspx
Biit of a novice, so unclear where to add the query string or subdomain logic.
Assume if I create a subdomain newclient.serviceprovider.com and point the home page to serviceprovider.com/newClientSSOSignIn.aspx
In it’s current state, I think it would still redirect me to the broader SignIn page right….
Where would I add the logic for the sub-domain or query string, would that be on the existing SignIn.aspx / SignIn.aspx.cs or a modification to my authentication stanza in my web.config
Still researching, but not sure what that will look like....
Thx again!
If SSO users will have a special URL (ie serviceprovider.com/newClientSSOSignIn.aspx), you don’t need a query string parameter etc.
This URL would be one that doesn’t require local login to access.
So, the sequence would be:
1. SSO user goes to this special URL.
2. Your application calls SAMLServiceProvider.InitiateSSO to send a SAM authn request to the IdP.
3. User logs in at IdP if they’re not already logged in.
4. IdP sends a SAML response to your application’s assertion consumer service endpoint.
5. Your application calls SAMLServiceProvider.ReceiveSSO to receive and process the SAML response.
6. You application automatically logs the user in and redirects to the home page etc.
This is totally independent from the non-SSO login.
This URL would be one that doesn't require local login to access.
So, the sequence would be:
1. SSO user goes to this special URL.
2. Your application calls SAMLServiceProvider.InitiateSSO to send a SAM authn request to the IdP.
3. User logs in at IdP if they're not already logged in.
4. IdP sends a SAML response to your application's assertion consumer service endpoint.
5. Your application calls SAMLServiceProvider.ReceiveSSO to receive and process the SAML response.
6. You application automatically logs the user in and redirects to the home page etc.
This is totally independent from the non-SSO login.
yea no, your spot on -
the very novice problem I am having is getting to step1.
If I create this webpage in my current .asp net webform app, serviceprovider.com/newClientSSOSignIn.aspx
It's automatically redirecting me to serviceprovider.com/SignIn.aspx
This URL would be one that doesn't require local login to access.
So, the sequence would be:
1. SSO user goes to this special URL.
2. Your application calls SAMLServiceProvider.InitiateSSO to send a SAM authn request to the IdP.
3. User logs in at IdP if they're not already logged in.
4. IdP sends a SAML response to your application's assertion consumer service endpoint.
5. Your application calls SAMLServiceProvider.ReceiveSSO to receive and process the SAML response.
6. You application automatically logs the user in and redirects to the home page etc.
This is totally independent from the non-SSO login.
yea no, your spot on -
the very novice problem I am having is getting to step1.
If I create this webpage in my current .asp net webform app, serviceprovider.com/newClientSSOSignIn.aspx
It's automatically redirecting me to serviceprovider.com/SignIn.aspx
[/quote]
Actually i think i might have figured it out (I THINK) .
Creating a new location tag for the new page with its own system.web props...
Still researching....
Thx
Ok. There are many ways to implement this. It just depends on your business requirements and existing implementation.