Hacker News Reader

Comment by willow9886 | Hacker News Reader

> that is close to okta functionality-wise?

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.

View on HN

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.

PingIdentity has a reasonable mech for this via their 'ping one' offering..

OneLogin... you mean like the guys who can't setup SSL Certs correctly?

https://www.pinterest.onelogin.com

That seems a bit harsh, it's a wildcard cert on onelogin.com and they have a 'catch all' DNS on there which will break ssl for anything above that:

https://massive.bag.of.dicks.pinterest.onelogin.com

Is www.pt.ol.com linked from anywhere?

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..

I mean:

https://bigger.bag.of.dicks.signin.aws.amazon.com/

Because those Certs weren't designed for this scenario.

The fact that you can create that domain name to resolve is funny. I can think of a few phishing schemes I could use with this, if I were so inclined.

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!

also, you can use https://pintrest.onelogin.com ;)

Yes, but they are resolving these names. In fact, they are resolving any names.

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

Thank you.

Keeping those thousands of predefined integrations aside, do you know of any good combination of user-management/access-management/federated-access system beside GLUU?

ForgeRock has a pretty comprehensive suite of open source IAM software [1] but you have to buy a subscription before you can put it into production.

There's also the open source KeyCloak project from RedHat. [2]

Also I believe Connect2ID is FOSS. [3]

[1] https://www.forgerock.com/

[2] http://www.keycloak.org/

[3] http://connect2id.com/

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.

Ping being PingFederate?

So chooseing among GLUU and those mentioned above (and OpenAM/WSO2 that you trashed =)) which one you'd go with ?

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.

I got your point. Makes me rethink the whole thing we might otherwise get ourselves into.

can't leave out mitreid connect http://mitreid-connect.github.io/

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!

Reply on news.ycombinator.com