Question: IdSrv 3 for enterprise-wide Identity Portal

[Peperud]

Hi,
We host thousands of companies, each with their own sets of applications (built by us), each of them with their set of users etc. Some companies share application instances, some have their own installs.
Last year, we implemented a SAML2 solution to allow using external SAML2 IdPs in some of the applications and it’s working well. Still there are the typical SAML issues with web services, mobile apps etc. which makes providing a truly SSO solution across different application (types) difficult.
Looking forward – the idea is to implement a different model, where we host a single identity server/portal, where we register all the companies. We should be able to provide each company with a login experience customized just for them – logo, address etc. on login screen or sending them to their external identity provider of choice (and skipping the consent page, since technically it’s us on both sides).
The identity server should also be able to handle dynamic company registrations (with or without specific for the client/company external IdP, 2FA and so on). The registration itself doesn’t need to happen through IdSrv, but it should be able to seamlessly pick it up and run with it.
After watching Dom’s presentation at the NDC 2014 conference, it’s clear to me that as far as protocol - OIDC is the way to go.
And naturally, after that the first think I looked at was the Identity Server 3. I like what I see so far.

But before I dive any deeper, I’d like to get an opinion, if IdSrv would be a good fit for my scenario or I should look elsewhere?

Apologies for not using proper terminology.
Thanks.

[brockallen]

IdSvr3 can be customized to support multi-tenancy, yes. I've done this for a customer of mine.

[Peperud]

Is there a way to dynamically on the fly configure the external providers?

Having to integrate with potentially hundreds (or thousands) of customers' IdPs and new settings have to be applied dynamically, without service interruption etc.
My understanding is that external providers end up as individual pieces of OWIN middleware. While this might be fine for a small static number of providers, it seems that it wouldn't scale well with hundreds (or thousands) for numbers of reasons:

1. Longer OWIN pipeline would have detrimental effect on performance...right?
2. Up-front configuration (on startup) is not flexible to dynamically accommodate configuration changes.
3. Rebuilding OWIN pipeline on demand after start-up, while generally possible, will still cause service interruptions...wouldn't it?

Am I way off? What am I missing?

[brockallen]

You can dynamically rebuilt the OWIN pipeline. If this isn't ideal, then ask Microsoft to build more flexible middleware :)

I've not tried it, but it's possible that you might be able to handle the various events and make the one middleware handle multiple STSs... but I'd not hold my breath.

[Peperud]

Thanks.

That's kind of what it seems I'm looking for - instead of a huge number of tightly configured pieces of authentication middleware in the OWIN pipeline, a small number of middleware pieces, each one handling a particular type of supported external authentication (oidc, saml, etc). The specific parameters for the external provider would be then dynamically configured in-flight based on the client.

Or perhaps - have an intermediary (ADFS or something else) to handle the external IdP integration and configure this intermediary as the only external STS in IdSrv (not sure how well the home realm discovery can be wired up in this case)...

P.S.
I know I can rebuilt the OWIN pipeline (3 above), but there will still be the longer pipeline issue and rebuilding the pipeline would still cause service interruption.

[brockallen]

Rebuilding would not interrupt the service -- you'd just do that work on a new thread and simply swap your pipeline app func when it's done. But that detail is moot, I suppose.

I guess what your requirement means is that the Microsoft middleware isn't designed for your scenario. You'll need to build your own middleware that handles this multi-tenant (or really massive tenant) scenario.