6 ms·

Personally I think of Authelia and Keratin as really good projects in the don't-build-auth-into-your-apps-ever-again space. If auth isn't already built into you

Personally I think of Authelia and Keratin as really good projects in the don't-build-auth-into-your-apps-ever-again space. If auth isn't already built into your app gateway/mesh/proxy, then these services might be something worth dropping alongside. A few more projects in this space: - Keycloak (you won't get fired for picking this)[0] - CloudFoundry's UAA[1] - Gluu [2] - ORY (Hydra + friends)[3] - Keratin [4] - OpenUnison [5] - Dex[6] - Netlify's GoTrue[7] All of these solutions are a bit different but here are some of the axes: - Whether or not they function as an OAuth provider - Whether they're centered around application-user-login via mechanisms like email/password, application auth, or SSO - Whether or not they serve as a proxy to another down-the-line OAuth provider (Dex, GoTrue) - GUI availability - F/OSS-ness (basically all of them have very permissive licenses) [EDIT] More entries for this list in another comment @ https://news.ycombinator.com/item?id=26411457 https://news.ycombinator.com/item?id=26411457 [0]: https://www.keycloak.org/ https://www.keycloak.org/ [1]: https://github.com/cloudfoundry/uaa https://github.com/cloudfoundry/uaa [2]: https://gluu.org/docs/gluu-server/4.2/ https://gluu.org/docs/gluu-server/4.2/ [3]: https://github.com/ory/hydra#what-is-ory-hydra https://github.com/ory/hydra#what-is-ory-hydra [4]: https://keratin.github.io/authn-server/ https://keratin.github.io/authn-server/ [5]: https://github.com/tremolosecurity/openunison https://github.com/tremolosecurity/openunison [6]: https://github.com/dexidp/dex https://github.com/dexidp/dex [7]: https://github.com/netlify/gotrue https://github.com/netlify/gotrue

dastx 6y ago
Looks like Keycloak's certificate is only valid with `www.`: https://www.keycloak.org/ https://www.keycloak.org/ > - Keycloak (you won't get fired for picking this)[0] Curious what you mean with "you won't get fired for picking this". Do you mean that it's good and easy to run, or something else?
- scrollaway 6y ago
  Keycloak is used by enterprise a lot. ISPs, Banks, etc. So it's a pretty safe choice if you are in that space.
- codefined 6y ago
  I think it comes from the phrase "no one ever got fired for buying IBM". Here, Keycloak is the incumbent for organisations.
  - mooreds 6y ago
    If you are looking for an open source solution, it is definitely the 800 lb gorilla. If you are looking for a commercial solution, I would say that the top competitors are Okta, Auth0, Azure AD, and Firebase (though the latter, from what I've heard, doesn't play nicely with standards).
    - hardwaresofton 6y ago
      And now that Okta and Auth0 are the same, the big two options are Okta/Auth0 and Azure AD. I don't know how much Firebase gets used at scale but the price "scales" so well that I think most people switch off of it after the MVP validation phase. Just conjecture though, no numbers to back that up -- an enterprise client is probably not going to use your product because it has Firebase login integration.
      - robertlagrant 6y ago
        I wouldn't say they're the same thing except from a brand name perspective. Okta is barely app-focused; much more enterprise SSO. Auth0 is extremely app-focused, although they can do some enterprise SSO as well. Okta bought Stormpath (and killed it) and now Auth0 because of this difference, and because there's a finite total addressable market for employees, but an almost infinite total addressable market for app users.
      - mooreds 6y ago
        > And now that Okta and Auth0 are the same, the big two options are Okta/Auth0 and Azure AD. I mean, it's yet to be determined how Okta and Auth0 are going to integrate. I have read that Okta has three sets of APIs, maybe Auth0 will be a fourth? > an enterprise client is probably not going to use your product because it has Firebase login integration. LOL. It might even be a negative signal. But I hear Firebase is thinking about supporting standard OAuth, which would be great.
- hardwaresofton 6y ago
  Appreciate the correction, got to it in time! And as others have noted, this is probably the most enterprise-grade/production-hardened solution out there in the list that I made that represents my current list in the F/OSS space. If I were to think hard about it, there are probably lots of much older options (depends on where you put the scope of AuthN to be, is LDAP a competitor?), but Keycloak is probably the one you're going to find the most resources and scrutiny around. A large financial institution I worked with two years ago was using Keycloak. I was annoyed with some UI bits and terminology that was very confusing but it was overall a great choice back then IMO, has probably mostly/only gotten better since.
vwpolo3 6y ago
Don't forget Ory: https://github.com/ory https://github.com/ory
- hardwaresofton 6y ago
  Yup, huge omission -- this was also on my list but for some reason I put in Gluu but not Ory
vidar 6y ago
https://fusionauth.io/ https://fusionauth.io/ also looks good
heywherelogingo 6y ago
Keycloak (you won't get fired for picking this) Not if you're just picking it, but possibly if you have to administer it. We're in the process of replacing it, possibly with Hydra.
- vetinari 6y ago
  We switched from Keycloak-on-CentOS to Keycloak-in-Docker, and it made configuration & updating so much easier. It is no longer necessary to fight with JBoss xml config, but there are nicely defined env vars to configure exactly the things that are interesting to anyone who uses Keycloak, instead of random Java stuff.
  - hardwaresofton 6y ago
    Please note this the next time someone in your organization or outside rails against dockerizing crucial infrastructure versus maintaining some well manicured packer/ansible/puppet/chef/salt scripts that rely on apt/deb/rpm/apk for instances that are occasionally manually tweaked in emergencies. Docker isn't always the right choice, but I personally feel a lot more empowered to run infrastructure pieces that are dockerized because the inputs and outputs are much more explicit and easier to manipulate and change in isolation (I don't have to remember 3 directories where config could be, I just mount the one volume for example).
    - 0xbadcafebee 6y ago
      When you want an off-the-shelf component that you don't have to tweak or maintain, Docker containers are fantastic. Most projects that publish a container also integrate features so you almost never have to build a custom image.
- hardwaresofton 6y ago
  I only had to deal with administering it once, and I didn't like the experience but also could have imagined the company picking so many things that would have been worse/more awkward to manage. I get a little intimidated by Ory's multi-app approach to all of it (who wants to deploy & manage 4 containers/VMs versus 1 with Keycloak?), but I know I need to give it a proper chance one of these days. Hydra seems to be a very polished entrant in the space.
jimlikeslimes 6y ago
IdentityServer 4 is another product of note in the .Net ecosystem.
mooreds 6y ago
One thing that is missing from this list is open source language specific libraries. Projects such as https://oauthlib.readthedocs.io/en/latest/oauth2/server.html https://oauthlib.readthedocs.io/en/latest/oauth2/server.html and https://github.com/doorkeeper-gem/doorkeeper https://github.com/doorkeeper-gem/doorkeeper Depending on your use case, for example if you only have one application, you might be better off running something embedded in your app, or independent but using the same runtime/deployment environment. Then, when you are ready to add another app or integration, you should be able to introduce a standalone auth system more easily if appropriate (because all your auth interactions should be relatively standardized). I'm a big fan of standalone auth systems as a way to simplify access control and give a single view of a user/customer, but you can also succeed using open source embedded libraries. When the moment comes to introduce a standalone system, you should consider a few dimensions (this list pulled from a previous comment of mine: https://news.ycombinator.com/item?id=26360048 https://news.ycombinator.com/item?id=26360048 ): * open source or not * standalone application or library/framework you integrate * self hosted or SaaS * authentication, authorization, user management or all three? * standards coverage * SSO support * integrations with other auth tech (LDAP) * which OAuth grants are supported * cost * operational complexity/support for your deployment environment * specific features if needed (for example, customization of the look and feel with themes, or customization of the login flow with something like Keycloak's plugin system) * documentation and developer experience These dimensions all matter to varying degrees depending on your team and needs. Disclosure: I work for https://fusionauth.io/ https://fusionauth.io/ which has open source supporting libraries and docs, but which is itself not open source. EDIT: added cost, operational complexity and customization to the list.
- hardwaresofton 6y ago
  I actually did exclude those on purpose, because I think they're somewhat out of scope -- arguably the point of running something like Authelia/Keratin/Dex/Keycloak/etc is to not write a single line of auth code, even if it's just wiring up a module/component. That said, here are some more in the space that I personally have earmarked: - (all-in-one) jsso2[0] - (all-in-one, embeddable) a12n-server[1] - (embeddable) node-oidc-provider[2] - (embeddable) node-oauth2-server[3] - (all-in-one, embeddable) authboss[4] - (proxy) vouch-proxy for NGINX[5] - (proxy) Grant with support for over 200 provider (!!)[6] [0]: https://github.com/jrockway/jsso2 https://github.com/jrockway/jsso2 [1]: https://github.com/curveball/a12n-server https://github.com/curveball/a12n-server [2]: https://github.com/panva/node-oidc-provider https://github.com/panva/node-oidc-provider [3]: https://github.com/oauthjs/node-oauth2-server https://github.com/oauthjs/node-oauth2-server [4]: https://github.com/volatiletech/authboss https://github.com/volatiletech/authboss [5]: https://github.com/vouch/vouch-proxy https://github.com/vouch/vouch-proxy [6]: https://github.com/simov/grant https://github.com/simov/grant
akvadrako 6y ago
I tried several of these recently and I ended up with glewlwyd: https://github.com/babelouest/glewlwyd https://github.com/babelouest/glewlwyd
- closeparen 6y ago
  A security-critical webapp written in C! Is there an audit report from anyone who's been at it with a fuzzer?
mamcx 6y ago
Exist other 2 major things that I have tried to find but is rarely missed: 1- GOOD multi-tenant support. Without extra weird hoops like with ORY. How this must be? Just passing a subdomain is all necessary to route and it need to make easy to create/remove tenants as part of MY logic, not need to orchestrate stuff. 2- Use my own tables. (or allow to set FX/new fields) I appreciate to have automated all the stuff but I have much logic around what is a "user" (and in a recent project, 2 kinds of user in 2 different tables: salesman/customers). Ideally, this stuff only need to do "SELECT fields_for_auth FROM my_table"
- eropple 6y ago
  > 2- Use my own tables. If managing data directly and personally is a requirement for you, then you probably don't want these tools. Part of the reason they exist is to manage user data (passwords, tokens, etc.) correctly and with minimal surprises. ORY Kratos, as an example, will happily create different conceptual types of users and you can store arbitrary data in those user documents, but it is modified through an API and exposes to you stable IDs against which you can code the rest of your application.
  - mamcx 6y ago
    The problem is that this tables are like "foreign" to the db, in a micro-service mindset (the worst anti-pattern to date!). That is a major complication. In Django, this solve neatly, because I can point to my own table or easily integrate the ones of Django without much fuss. This turn all this in a non-issue.
    - eropple 6y ago
      Yes, they're foreign to your application's database. That's the point: by using these tools you're buying into a service-oriented architecture. What you are advocating is to collapse the service-oriented architecture into a "everybody parties on the database" architecture. These tools are very much invested in you not doing that. There already exist user-auth libraries for what you want and run inside your application itself.
irotatori 6y ago
For such critical services, it would be nice to have some security evaluation, if external security audits were made etc.
3np 6y ago
What’s your pick for LDAP + Free? OpenLDAP is arcane, freeipa is complex and has so many moving pieces.
- hardwaresofton 6y ago
  Unfortunately I don't have one -- all I've got saved is precisely OpenLDAP and FreeIPA. Though I do have this saved: https://github.com/i-core/werther https://github.com/i-core/werther It's a bit of a mouthfull: > Werther is an Identity Provider for ORY Hydra over LDAP. It implements Login And Consent Flow and provides basic UI. So basically, turn your LDAP into OAuth2, if I'm reading the features right: > Support Active Directory; > Mapping LDAP attributes to OpenID Connect claims; > Mapping LDAP groups to user roles; > OAuth 2.0 scopes; > Caching users roles; > UI customization. Unfortunately this doesn't really free you from maintaining an LDAP server, it just... let's you login using OAuth instead, by bringing pieces of the ORY ecosystem along.
  - 3np 6y ago
    If anything I'd like something like the inverse of Werther - I don't necessarily want to have a complete LDAP db and setup. It's just those couple of softwares that support LDAP and nothing else, so just providing an LDAP authentication interface to some other auth/identity solution would be great. Not having the time to implement that ourselves, we're stuck with LDAP as a backend as the common denominator.
    - hardwaresofton 6y ago
      Ahhhh, so that's really interesting, LDAP as the frontend to an anything-but-LDAP backend! This feels like it might exist so I went looking, looks like Auth0 had this[0][1]. I'm not sure there are any open source projects that actually do this ldap-in-the-front-something-else-in-the-back, but you can get very close: - https://github.com/glauth/glauth https://github.com/glauth/glauth (ldap in front, local file/s3/ldap in the back, extensible) - https://github.com/kernel164/go389 https://github.com/kernel164/go389 (ldap in front, YAML file in the back) Seems like this is quite the unsolved problem (unless you're using Auth0). Maybe it's worth using Auth0 only for this. If you're going with the F/OSS solutions then it feels like you could either add a plugin (DB, OAuth maybe?) to glauth, or hack together some sort of system that updates the YAML/S3 as accounts get added. [EDIT] - Also looks like Joyent has put together a framework for LDAP clients and servers in JS... (http://ldapjs.org/server.html http://ldapjs.org/server.html). The raw pieces are there but someone would really need to put them together to offer the facade. [EDIT2] - Also in go: https://github.com/vjeantet/ldapserver https://github.com/vjeantet/ldapserver [EDIT3] - Original code listing for auth0's connector (https://github.com/auth0/auth0-ldap-endpoint https://github.com/auth0/auth0-ldap-endpoint), lib/routes/authenticate.js looks very easy to work around... [0]: https://auth0.com/docs/extensions/ad-ldap-connector https://auth0.com/docs/extensions/ad-ldap-connector [1]: https://github.com/auth0/ad-ldap-connector https://github.com/auth0/ad-ldap-connector
xtracto 6y ago
Thanks for this list, it is very useful. Do you know of a "real world" example use for Keratin Authn? I see the diagrams and it looks like it could be useful but it kind of looks like moving the login/password part of the backend to another service (OK), but what happens with authorization? (user roles have ability to do specific tasks)
- vbsteven 6y ago
  I don’t know about real world implementations but to answer the last question: IMO authorization responsibility belongs to the backend service. I like setups where the API Gateway talks to Keycloak for authenticating a request and passes a JWT with user/role info to the backend. The backend can then use the info from the JWT to perform authorization, and if necessary performs extra queries against an ACL table (or service).
anarcat 6y ago
would be great to have that in a table somewhere. ;)
- hardwaresofton 6y ago
  Suggestions? GitLab/GitHub? I don't really use Google sheets and these links actually just come out of my book marks (I've got a 'Self-Hosted > Authentication' folder) and years of bookmarking. Maybe one of the awesome-<x> lists?
  - anarcat 6y ago
    one of the problems with the "awesome" lists is exactly that: it's just one huge list, and it's hard to tell what's what. maybe just a gist with a markdown table? or maybe expanding on this: https://en.wikipedia.org/wiki/List_of_single_sign-on_implementations https://en.wikipedia.org/wiki/List_of_single_sign-on_impleme... ... if you have the courage of dealing with Mediawiki tables (although the WYSIWYG editor has improved kind of enough to make that workable nowadays...)
    - hardwaresofton 6y ago
      hmnnn yeah the discoverability problem is a bit of an issue with the gist, and wikipedia seems better but that page is kind of right but not quite...
closeparen 6y ago
I would really like to see an open source IDP that can be run as a Lambda or similar for small scale employee OAuth, etc. without a permanent VM footprint. I’d write one, of course, but I’d be nervous about doing security critical code as a hobby. Do any exist?
- o-__-o 6y ago
  IDP? https://simplesamlphp.org/ https://simplesamlphp.org/ Would fit that bill.

dastx 6y ago

Looks like Keycloak's certificate is only valid with `www.`: https://www.keycloak.org/ https://www.keycloak.org/ > - Keycloak (you won't get fired for picking this)[0] Curious what you mean with "you won't get fired for picking this". Do you mean that it's good and easy to run, or something else?

scrollaway 6y ago
Keycloak is used by enterprise a lot. ISPs, Banks, etc. So it's a pretty safe choice if you are in that space.
codefined 6y ago
I think it comes from the phrase "no one ever got fired for buying IBM". Here, Keycloak is the incumbent for organisations.
- mooreds 6y ago
  If you are looking for an open source solution, it is definitely the 800 lb gorilla. If you are looking for a commercial solution, I would say that the top competitors are Okta, Auth0, Azure AD, and Firebase (though the latter, from what I've heard, doesn't play nicely with standards).
  - hardwaresofton 6y ago
    And now that Okta and Auth0 are the same, the big two options are Okta/Auth0 and Azure AD. I don't know how much Firebase gets used at scale but the price "scales" so well that I think most people switch off of it after the MVP validation phase. Just conjecture though, no numbers to back that up -- an enterprise client is probably not going to use your product because it has Firebase login integration.
    - robertlagrant 6y ago
      I wouldn't say they're the same thing except from a brand name perspective. Okta is barely app-focused; much more enterprise SSO. Auth0 is extremely app-focused, although they can do some enterprise SSO as well. Okta bought Stormpath (and killed it) and now Auth0 because of this difference, and because there's a finite total addressable market for employees, but an almost infinite total addressable market for app users.
    - mooreds 6y ago
      > And now that Okta and Auth0 are the same, the big two options are Okta/Auth0 and Azure AD. I mean, it's yet to be determined how Okta and Auth0 are going to integrate. I have read that Okta has three sets of APIs, maybe Auth0 will be a fourth? > an enterprise client is probably not going to use your product because it has Firebase login integration. LOL. It might even be a negative signal. But I hear Firebase is thinking about supporting standard OAuth, which would be great.
hardwaresofton 6y ago
Appreciate the correction, got to it in time! And as others have noted, this is probably the most enterprise-grade/production-hardened solution out there in the list that I made that represents my current list in the F/OSS space. If I were to think hard about it, there are probably lots of much older options (depends on where you put the scope of AuthN to be, is LDAP a competitor?), but Keycloak is probably the one you're going to find the most resources and scrutiny around. A large financial institution I worked with two years ago was using Keycloak. I was annoyed with some UI bits and terminology that was very confusing but it was overall a great choice back then IMO, has probably mostly/only gotten better since.

vwpolo3 6y ago

Don't forget Ory: https://github.com/ory https://github.com/ory

hardwaresofton 6y ago
Yup, huge omission -- this was also on my list but for some reason I put in Gluu but not Ory

vidar 6y ago

https://fusionauth.io/ https://fusionauth.io/ also looks good

heywherelogingo 6y ago

Keycloak (you won't get fired for picking this) Not if you're just picking it, but possibly if you have to administer it. We're in the process of replacing it, possibly with Hydra.

vetinari 6y ago
We switched from Keycloak-on-CentOS to Keycloak-in-Docker, and it made configuration & updating so much easier. It is no longer necessary to fight with JBoss xml config, but there are nicely defined env vars to configure exactly the things that are interesting to anyone who uses Keycloak, instead of random Java stuff.
- hardwaresofton 6y ago
  Please note this the next time someone in your organization or outside rails against dockerizing crucial infrastructure versus maintaining some well manicured packer/ansible/puppet/chef/salt scripts that rely on apt/deb/rpm/apk for instances that are occasionally manually tweaked in emergencies. Docker isn't always the right choice, but I personally feel a lot more empowered to run infrastructure pieces that are dockerized because the inputs and outputs are much more explicit and easier to manipulate and change in isolation (I don't have to remember 3 directories where config could be, I just mount the one volume for example).
  - 0xbadcafebee 6y ago
    When you want an off-the-shelf component that you don't have to tweak or maintain, Docker containers are fantastic. Most projects that publish a container also integrate features so you almost never have to build a custom image.
hardwaresofton 6y ago
I only had to deal with administering it once, and I didn't like the experience but also could have imagined the company picking so many things that would have been worse/more awkward to manage. I get a little intimidated by Ory's multi-app approach to all of it (who wants to deploy & manage 4 containers/VMs versus 1 with Keycloak?), but I know I need to give it a proper chance one of these days. Hydra seems to be a very polished entrant in the space.

jimlikeslimes 6y ago

IdentityServer 4 is another product of note in the .Net ecosystem.

mooreds 6y ago

One thing that is missing from this list is open source language specific libraries. Projects such as https://oauthlib.readthedocs.io/en/latest/oauth2/server.html https://oauthlib.readthedocs.io/en/latest/oauth2/server.html and https://github.com/doorkeeper-gem/doorkeeper https://github.com/doorkeeper-gem/doorkeeper Depending on your use case, for example if you only have one application, you might be better off running something embedded in your app, or independent but using the same runtime/deployment environment. Then, when you are ready to add another app or integration, you should be able to introduce a standalone auth system more easily if appropriate (because all your auth interactions should be relatively standardized). I'm a big fan of standalone auth systems as a way to simplify access control and give a single view of a user/customer, but you can also succeed using open source embedded libraries. When the moment comes to introduce a standalone system, you should consider a few dimensions (this list pulled from a previous comment of mine: https://news.ycombinator.com/item?id=26360048 https://news.ycombinator.com/item?id=26360048 ): * open source or not * standalone application or library/framework you integrate * self hosted or SaaS * authentication, authorization, user management or all three? * standards coverage * SSO support * integrations with other auth tech (LDAP) * which OAuth grants are supported * cost * operational complexity/support for your deployment environment * specific features if needed (for example, customization of the look and feel with themes, or customization of the login flow with something like Keycloak's plugin system) * documentation and developer experience These dimensions all matter to varying degrees depending on your team and needs. Disclosure: I work for https://fusionauth.io/ https://fusionauth.io/ which has open source supporting libraries and docs, but which is itself not open source. EDIT: added cost, operational complexity and customization to the list.

hardwaresofton 6y ago
I actually did exclude those on purpose, because I think they're somewhat out of scope -- arguably the point of running something like Authelia/Keratin/Dex/Keycloak/etc is to not write a single line of auth code, even if it's just wiring up a module/component. That said, here are some more in the space that I personally have earmarked: - (all-in-one) jsso2[0] - (all-in-one, embeddable) a12n-server[1] - (embeddable) node-oidc-provider[2] - (embeddable) node-oauth2-server[3] - (all-in-one, embeddable) authboss[4] - (proxy) vouch-proxy for NGINX[5] - (proxy) Grant with support for over 200 provider (!!)[6] [0]: https://github.com/jrockway/jsso2 https://github.com/jrockway/jsso2 [1]: https://github.com/curveball/a12n-server https://github.com/curveball/a12n-server [2]: https://github.com/panva/node-oidc-provider https://github.com/panva/node-oidc-provider [3]: https://github.com/oauthjs/node-oauth2-server https://github.com/oauthjs/node-oauth2-server [4]: https://github.com/volatiletech/authboss https://github.com/volatiletech/authboss [5]: https://github.com/vouch/vouch-proxy https://github.com/vouch/vouch-proxy [6]: https://github.com/simov/grant https://github.com/simov/grant

akvadrako 6y ago

I tried several of these recently and I ended up with glewlwyd: https://github.com/babelouest/glewlwyd https://github.com/babelouest/glewlwyd

closeparen 6y ago
A security-critical webapp written in C! Is there an audit report from anyone who's been at it with a fuzzer?

mamcx 6y ago

Exist other 2 major things that I have tried to find but is rarely missed: 1- GOOD multi-tenant support. Without extra weird hoops like with ORY. How this must be? Just passing a subdomain is all necessary to route and it need to make easy to create/remove tenants as part of MY logic, not need to orchestrate stuff. 2- Use my own tables. (or allow to set FX/new fields) I appreciate to have automated all the stuff but I have much logic around what is a "user" (and in a recent project, 2 kinds of user in 2 different tables: salesman/customers). Ideally, this stuff only need to do "SELECT fields_for_auth FROM my_table"

eropple 6y ago
> 2- Use my own tables. If managing data directly and personally is a requirement for you, then you probably don't want these tools. Part of the reason they exist is to manage user data (passwords, tokens, etc.) correctly and with minimal surprises. ORY Kratos, as an example, will happily create different conceptual types of users and you can store arbitrary data in those user documents, but it is modified through an API and exposes to you stable IDs against which you can code the rest of your application.
- mamcx 6y ago
  The problem is that this tables are like "foreign" to the db, in a micro-service mindset (the worst anti-pattern to date!). That is a major complication. In Django, this solve neatly, because I can point to my own table or easily integrate the ones of Django without much fuss. This turn all this in a non-issue.
  - eropple 6y ago
    Yes, they're foreign to your application's database. That's the point: by using these tools you're buying into a service-oriented architecture. What you are advocating is to collapse the service-oriented architecture into a "everybody parties on the database" architecture. These tools are very much invested in you not doing that. There already exist user-auth libraries for what you want and run inside your application itself.

irotatori 6y ago

For such critical services, it would be nice to have some security evaluation, if external security audits were made etc.

3np 6y ago

What’s your pick for LDAP + Free? OpenLDAP is arcane, freeipa is complex and has so many moving pieces.

hardwaresofton 6y ago
Unfortunately I don't have one -- all I've got saved is precisely OpenLDAP and FreeIPA. Though I do have this saved: https://github.com/i-core/werther https://github.com/i-core/werther It's a bit of a mouthfull: > Werther is an Identity Provider for ORY Hydra over LDAP. It implements Login And Consent Flow and provides basic UI. So basically, turn your LDAP into OAuth2, if I'm reading the features right: > Support Active Directory; > Mapping LDAP attributes to OpenID Connect claims; > Mapping LDAP groups to user roles; > OAuth 2.0 scopes; > Caching users roles; > UI customization. Unfortunately this doesn't really free you from maintaining an LDAP server, it just... let's you login using OAuth instead, by bringing pieces of the ORY ecosystem along.
- 3np 6y ago
  If anything I'd like something like the inverse of Werther - I don't necessarily want to have a complete LDAP db and setup. It's just those couple of softwares that support LDAP and nothing else, so just providing an LDAP authentication interface to some other auth/identity solution would be great. Not having the time to implement that ourselves, we're stuck with LDAP as a backend as the common denominator.
  - hardwaresofton 6y ago
    Ahhhh, so that's really interesting, LDAP as the frontend to an anything-but-LDAP backend! This feels like it might exist so I went looking, looks like Auth0 had this[0][1]. I'm not sure there are any open source projects that actually do this ldap-in-the-front-something-else-in-the-back, but you can get very close: - https://github.com/glauth/glauth https://github.com/glauth/glauth (ldap in front, local file/s3/ldap in the back, extensible) - https://github.com/kernel164/go389 https://github.com/kernel164/go389 (ldap in front, YAML file in the back) Seems like this is quite the unsolved problem (unless you're using Auth0). Maybe it's worth using Auth0 only for this. If you're going with the F/OSS solutions then it feels like you could either add a plugin (DB, OAuth maybe?) to glauth, or hack together some sort of system that updates the YAML/S3 as accounts get added. [EDIT] - Also looks like Joyent has put together a framework for LDAP clients and servers in JS... (http://ldapjs.org/server.html http://ldapjs.org/server.html). The raw pieces are there but someone would really need to put them together to offer the facade. [EDIT2] - Also in go: https://github.com/vjeantet/ldapserver https://github.com/vjeantet/ldapserver [EDIT3] - Original code listing for auth0's connector (https://github.com/auth0/auth0-ldap-endpoint https://github.com/auth0/auth0-ldap-endpoint), lib/routes/authenticate.js looks very easy to work around... [0]: https://auth0.com/docs/extensions/ad-ldap-connector https://auth0.com/docs/extensions/ad-ldap-connector [1]: https://github.com/auth0/ad-ldap-connector https://github.com/auth0/ad-ldap-connector

xtracto 6y ago

Thanks for this list, it is very useful. Do you know of a "real world" example use for Keratin Authn? I see the diagrams and it looks like it could be useful but it kind of looks like moving the login/password part of the backend to another service (OK), but what happens with authorization? (user roles have ability to do specific tasks)

vbsteven 6y ago
I don’t know about real world implementations but to answer the last question: IMO authorization responsibility belongs to the backend service. I like setups where the API Gateway talks to Keycloak for authenticating a request and passes a JWT with user/role info to the backend. The backend can then use the info from the JWT to perform authorization, and if necessary performs extra queries against an ACL table (or service).

anarcat 6y ago

would be great to have that in a table somewhere. ;)

hardwaresofton 6y ago
Suggestions? GitLab/GitHub? I don't really use Google sheets and these links actually just come out of my book marks (I've got a 'Self-Hosted > Authentication' folder) and years of bookmarking. Maybe one of the awesome-<x> lists?
- anarcat 6y ago
  one of the problems with the "awesome" lists is exactly that: it's just one huge list, and it's hard to tell what's what. maybe just a gist with a markdown table? or maybe expanding on this: https://en.wikipedia.org/wiki/List_of_single_sign-on_implementations https://en.wikipedia.org/wiki/List_of_single_sign-on_impleme... ... if you have the courage of dealing with Mediawiki tables (although the WYSIWYG editor has improved kind of enough to make that workable nowadays...)
  - hardwaresofton 6y ago
    hmnnn yeah the discoverability problem is a bit of an issue with the gist, and wikipedia seems better but that page is kind of right but not quite...

closeparen 6y ago

I would really like to see an open source IDP that can be run as a Lambda or similar for small scale employee OAuth, etc. without a permanent VM footprint. I’d write one, of course, but I’d be nervous about doing security critical code as a hobby. Do any exist?

o-__-o 6y ago
IDP? https://simplesamlphp.org/ https://simplesamlphp.org/ Would fit that bill.