The power of OKTA lies in its thousands of pre-configured SSO relationships. It's important to remember that each one was set up manually with a unique client ID and secret, metadata file, etc.
Application integration is the most difficult part of most identity and access management projects. That is why outsourcing identity to a SaaS provider like OKTA or OneLogin is so appealing--they have done all the hard work for you.
There are no open source projects like OKTA because if you're using open source software, you will inevitably have to integrate and test each application you want configured for SSO.
Also, God help you when it's time to swap out your IdP's signing certificate... almost no SPs/RPs support automatic metadata retrieval and updating, so a mad rush to do everything on a Saturday is par for the course. Some, but not most, IdPs support granular signing certificate config.
The fact they have a "catch all" DNS resolver for an SSL-based website that is an interface for admins and end users alike that is guaranteed to fail says a lot about their ability to sell a secure product.
And how else would you let your users have a subdomain login url? Why bother generating specific certs and dns for each when you can just use the HOST header for the login and use a wildcard?
This is totally common and used in a lot of places..
This was designed for exactly that sort of scenario. If you're runnin a SAAS then this is totally common practice, it's used by at least AWS, Slack, and GitHub off the top of my head.. Are you saying these companies are doing something stupid?
How could you phish github or aws by using their dns/cert setup as they intended it to be used?
That's more of the nature of SSL certs than their inability to set them up correctly. *.example.com covers www.example.com, but not www.something.example.com. And as far as i know, you can't get a "super wildcard" cert that allows that.
If I'm wrong on the last point, please let me know, as I know a lot of people that will be very happy to find out!
The power also lies in it's ability to be used as an external userstore that can be called via API's from your own app as well as oidc/integrated mfa support
Keeping those thousands of predefined integrations aside, do you know of any good combination of user-management/access-management/federated-access system beside GLUU?
One thing to keep in mind is that Gluu is an IAM platform, not just an OpenID Connect Provider. It's a comprehensive suite that includes both central authentication, authorization, FIDO authentication (and support for many two factor technologies), mobile software, client software. Starting in version 3.0, we will bundle a special version of OpenLDAP, provided by Symas (another great FOSS vendor), specifically optimized for the Gluu Server.
An IAM platform is many products integrated together, and operationally scalable to meet mission critical requirements. An OpenID Provider is just one element of an IAM platform!
You don't, actually, but you need to build it yourself instead of using their binaries (it's OSS).
Friends don't let friends OpenAM though, don't bother with WSO2 either. I'd do everything possible to make this someone else's problem, and if you absolutely have to do it in house then ping's the easiest I've worked with thus far.
Given any sort of control on such a project; I'd push as hard as possible to outsource that component and make it someone else's problem and try to stay as far away as possible from the whole show.
Making a SSO, even with nice friendly software (hint: none of it is, it's really really complex and easy to fuck up, and the stakes are pretty high) is a horrible, horrible, experience and if you've been through it you'll probably never want to do it again.
I've done it twice, perhaps I was just unlucky but it'll take a lot to convince me that the smarter plan isn't just to outsource that whole requirement instead of trying to build it / OSS it in house. It's pretty generic and can be a 'black box' on your arch diagram, your time is probably better spent building business specific things instead...
If I was absolutely forced to pick something to run on prem for IDP/Fed/Entitlement, I'd get the pingidentity onsite and have them build it for me (trust me, this will be cheaper than trying to do it yourself even if their day rate makes your eyes bleed).
I'd quit before seeing the OpenAM mgt console again.
