So here is the situation. We have internal clients (signin with ADFS), External clients (signin with internal username password.) and public pages. (an about page, splash page, general info pages.)
I’ve taken the high level api to get SSO working with all pages, which was a good start, but now I need to have the public pages be available and be able to support external clients. (users with no ADFS credentials.)
I am thinking that this means I need to solve this with a multi tenancy solution.
Where I create my own IdP for External clients to use, (and give a token result for public pages.)
Then I would need to resolve the case where the user moves from a public page to an internal page and they need to login with either IdP.
The problem for me is that this sounds like a fairly complicated solution… Is there an easier one that I’m missing?
(Other then separating public/External users to their own site with the existing functionality, and the Internals to a different site with ADFS SSO.)
Thanks!
Darren
Hi Darren
Will the external clients be logging into their own web sites? In other words, are these external sites identity providers that are SSO’ing to your service provider site?
Generally, if these are external users (ie no ADFS credentials) then they should log into their own site and then SSO to your site.
I may not be fully understanding your requirements so please feel free to expand on them.
Here are the details. You can think of our product as a web site store. (The site store is my SP)
We have Internal (will login with ADFS), External (will login with Username/Password, more on that.) and public users.
The public users will be able to see the public pages, (catalogs, about, FAQ, etc…)
However once they want to buy or use the content they need to be logged in.
The External users normally login with our own Username/Password pages.
I’m going through re-skinning and changing the High Level IdP Example for them.
As well, we’ll have Internals using ADFS, so I’ll need to put them both together for Multi-Tenancy on the SP implementation.
The only thing I can think of that I’ll still need for these two is a link or something on the External IdP to allow a user to choose to login via ADFS.
(SP-initiated SSO, should go to the External first, but if the user has ADFS credentials but isn’t logged in ATM they should have the option.)
Other then that there is the generic public functionality.
The only solution I can think of is a pseudo-IdP or additional functionality to the External IdP.
So that if the user is looking at a public page and they are not logged in, we issue generic credentials that expire in like 4s.
Am I right that I need to do Multi-Tenancy for Internal/External users?
Am I on the right track for the best solution for public access?
Thanks for the additional details.
Multi-tenancy is only required if you have per-tenant SAML configurations. This means there would be a completely separate SAML configuration per tenant. If your SP has to have separate SAML configurations for each tenant then you would use the multi-tenancy support.
If your SP has to support multiple IdPs (eg for internal users and for external users) then this doesn’t require a multi-tenancy configuration. You can have a single SAML configuration for your SP that supports multiple partner IdPs. The ExampleServiceProvider project’s saml.config includes multiple entries.
Your SP’s saml.config would include a single entry which represents your SP. It would include a entry for ADFS used by internal users and a entry for the external IdP used by external users.
For the public functionality that doesn’t require a login, couldn’t you use the standard ASP.NET web.config support to specify which pages require the user to be authorized and which pages are generally accessible? You would make the public pages accessible without requiring a logged in user. The other content would require a logged in user (either via SSO from ADFS or the external IdP).
For the public functionality that doesn't require a login, couldn't you use the standard ASP.NET web.config support to specify which pages require the user to be authorized and which pages are generally accessible? You would make the public pages accessible without requiring a logged in user. The other content would require a logged in user (either via SSO from ADFS or the external IdP).
Ah, I'm glad I don't have to go to the extra work of building multi-tenancy then. I do wonder how the SP chooses which IdP to connect to when the user has no credentials to either.
(I think I'd need some code to put in a default External IdP to put a link to the Internal IdP so the user can have the option to switch in that direction.)
I'm not a .NET managed code programmer type, but lately I play one at work. (Actually I do TSQL, VB, and some JS/HTML work, it's been 10+ yrs since I did any C/C++)
Thanks for the tip on web.config.. I'll look into that.
For SP-initiated SSO where there are multiple partner IdPs you need some way to determine which IdP to use for SSO.
The exact mechanism will be dependent on your application requirements.
For example, you could present a login page with a number of options. The user selects an option which then determines which IdP to SSO to.
Alternatively, users may come in at different entry points to your web site and this determines which IdP to use.
Or, if you have internal users and external users, you may use the user’s IP address to determine this and pick the correct IdP accordingly.
I’m sure there are many other ways to determine which IdP to use.
Just pick the method that best suits your requirements.