[HN Gopher] Authelia is an open-source authentication/authorizat...
___________________________________________________________________
Authelia is an open-source authentication/authorization server with
2FA/SSO
Author : thunderbong
Score : 258 points
Date : 2021-03-10 10:29 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| hardwaresofton wrote:
| 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
|
| [0]: https://www.keycloak.org/
|
| [1]: https://github.com/cloudfoundry/uaa
|
| [2]: https://gluu.org/docs/gluu-server/4.2/
|
| [3]: https://github.com/ory/hydra#what-is-ory-hydra
|
| [4]: https://keratin.github.io/authn-server/
|
| [5]: https://github.com/tremolosecurity/openunison
|
| [6]: https://github.com/dexidp/dex
|
| [7]: https://github.com/netlify/gotrue
| xtracto wrote:
| 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 wrote:
| 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).
| akvadrako wrote:
| I tried several of these recently and I ended up with glewlwyd:
|
| https://github.com/babelouest/glewlwyd
| vidar wrote:
| https://fusionauth.io/ also looks good
| irotatori wrote:
| For such critical services, it would be nice to have some
| security evaluation, if external security audits were made etc.
| closeparen wrote:
| 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?
| heywherelogingo wrote:
| _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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| dastx wrote:
| Looks like Keycloak's certificate is only valid with `www.`:
| 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?
| hardwaresofton wrote:
| 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.
| scrollaway wrote:
| Keycloak is used by enterprise a lot. ISPs, Banks, etc. So
| it's a pretty safe choice if you are in that space.
| codefined wrote:
| I think it comes from the phrase "no one ever got fired for
| buying IBM". Here, Keycloak is the incumbent for
| organisations.
| mooreds wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| zokier wrote:
| Also noting that these days IBM is the main force behind
| Keycloak (through RedHat acquisition), so the saying fits
| even better.
| anarcat wrote:
| would be great to have that in a table somewhere. ;)
| jimlikeslimes wrote:
| IdentityServer 4 is another product of note in the .Net
| ecosystem.
| 3np wrote:
| What's your pick for LDAP + Free? OpenLDAP is arcane, freeipa
| is complex and has so many moving pieces.
| mooreds wrote:
| 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
| and 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 ):
| * 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/ 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 wrote:
| 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
|
| [1]: https://github.com/curveball/a12n-server
|
| [2]: https://github.com/panva/node-oidc-provider
|
| [3]: https://github.com/oauthjs/node-oauth2-server
|
| [4]: https://github.com/volatiletech/authboss
|
| [5]: https://github.com/vouch/vouch-proxy
|
| [6]: https://github.com/simov/grant
| core-questions wrote:
| I am using vouch-proxy as it is a very simple addon that
| lets me use my existing OpenID Connect compatible IDP for
| authentication on anything fronted by Nginx. This works
| really well for services not really designed to have their
| own auth.
|
| The only downside is that it seems to require a second DNS
| entry for the vouch portion of the process. Awkward
| configuration in some ways. But, the price is right, and
| the Nginx config is reasonably clean once you understand
| what it's doing.
| vwpolo3 wrote:
| Don't forget Ory:
|
| https://github.com/ory
| hardwaresofton wrote:
| Yup, huge omission -- this was also on my list but for some
| reason I put in Gluu but not Ory
| mamcx wrote:
| 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"
| lmeyerov wrote:
| re:multitenant, is keycloak the only good + stable oss path?
| phumberdroz wrote:
| Keycloak has a couple of things than can go wrong with
| multi tenancy especially if you consider using one keycloak
| realm for each customer after 100 realms keycloak can just
| become unresponsive and the tokens from the master admin
| realm become to big.
| (https://issues.redhat.com/browse/KEYCLOAK-4593)
| polskibus wrote:
| What would be better than Keycloak then?
| eropple wrote:
| _> 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 wrote:
| 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 wrote:
| 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.
| mamcx wrote:
| What is a "stable IDs"?
| hc-taway wrote:
| > 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.
|
| The stable-ID solution was how I handled this when I wrote
| one of these as an internal tool (guess you'd call it a
| "microservice") for a startup I worked for back in like
| 2010. In hindsight I guess I should have pushed to pivot to
| selling _that_ as our product since we ended up selling the
| company for barely-pay-back-the-investors money, but who
| knew? Hahaha.
|
| Also identified permissionable-objects as UUIDs, which let
| me handle authorization in addition to authentication.
| Creating a new "permission" object meant asking for one
| from the service, then you'd receive a UUID, associate that
| with whatever thing you were applying the permissions to on
| your end, and tell the service to assign the desired
| permissions. Then you could just query the permissions for
| that UUID (which could, potentially, represent a bundle of
| items, a single item, or permissions to an entire service--
| how to interpret it was left up to the consuming service)
| and of course cache them as much as you felt was proper.
| IIRC there as also a concept of owning-objects so you could
| let permissions be inherited, then override on a case-by-
| case basis, plus it'd let you ask which objects belonged to
| a given collection. IIRC I used that to represent
| organizations, too, since they were basically the same
| thing as a permissionable-object container themselves
| needing to be permissionable.
|
| Not a perfectly-flexible system (billions of items that all
| need distinct permissions might have eventually forced
| sharding or something, but luckily we didn't have to worry
| about that) but it was rock solid for our purposes and made
| spinning up new services or products sharing login with our
| main product super-easy.
| James-E wrote:
| One of the Authelia devs here. Authelia actually in 4.27.0
| supports matching the user name as a subdomain in a rule, or
| a group name.
|
| Ideally long term we'll add regex support for
| usernames/groups in both path's and domains so that people
| can customize this further.
| James-E wrote:
| As a side note, I'd be willing to work specifically with
| someone wishing to utilize this to improve it. Feel free to
| reach out on our matrix or discord.
| mooreds wrote:
| > GOOD multi-tenant support.
|
| Is this so you can easily private label the application? Or
| is there some other use case for which multi tenant support
| is critical?
|
| > Use my own tables. (or allow to set FX/new fields)
|
| I'm not sure what 'FX' is (maybe a typo for 'FK'?).
|
| Do you mean the ability to store arbitrary data on the
| objects provided by the auth system (even if it is via API
| like a sibling comment mentions) or are you talking about the
| ability to create tables or have a foreign key directly into
| your application's database? Would stable GUIDs solve this
| for you?
| mamcx wrote:
| > Or is there some other use case for which multi tenant
| support is critical?
|
| To support multi tenants in software-as-services. I need to
| support "company1.app.com, company2.app.com" in my apps.
|
| > Do you mean the ability to store arbitrary data on the
| objects provided by the auth system...
|
| The thing is that a "user" have different means. I have
| salesman's, customers, operators, etc.
|
| Them have fields, like email, is_active, personal info,
| that are critical for the logic of the app.
|
| IDEALLY the auth server manage the security and read only
| the fields that are needed to operate this (like for send a
| password reset).
|
| The other fields, triggers, indexes, etc are more important
| the rest of the time.
|
| And I don't want to use a "will create corrupted integrity
| for sure, aka: micro services" because I work in the "sync
| data across dbs" and it ALWAYS will happened if data is not
| in single transaction.
| mooreds wrote:
| I have definitely seen folks use the id created by the
| auth system but nothing else. Everything else keys off
| the GUID, which should be immutable, and is stored in
| application specific tables.
|
| The password and username are in the auth system, but
| everything else stays in control of the application, in
| one database.
|
| I don't see why you couldn't use that pattern no matter
| which external auth provider you are using. You'd just
| give up things like self service registration, but that
| may be the right choice for your app.
| 411111111111111 wrote:
| The only sso provider I've really used is keycloak, so I am
| looking forward to having more lightweight alternative in this
| domain! though it doesn't seem to be a oidc server yet.
|
| What confused me a little is that it aims to put the
| authentication into the proxy layer, which sounds awesome... But
| I haven't been able to figure out from the docs how I'd be able
| to identify the user in my application now?
|
| /Edit: it's set as a header and can be verified it seems
|
| https://www.authelia.com/docs/deployment/supported-proxies/#...
| rad_gruchalski wrote:
| With the ory platform one could use their oathkeeper but also
| Traefik with forward auth plugin would work. The latter gives
| more options. Food for thought, I'm sure Traefik forward auth
| would work here too.
| James-E wrote:
| One of the Authelia devs here. This is correct. Also we're
| looking to implement OIDC/OAuth2.0 provider functionality. It
| has been somewhat delayed by COVID19, specifically additional
| personal burdens that arose because of it.
| 1cvmask wrote:
| Acmelogin also has default 2fa support:
|
| https://acmelogin.com/
|
| Disclosure: affiliated with it.
| exabrial wrote:
| Looking forward to the deb package! I like every part of what you
| guys are doing.
| sandreas wrote:
| Maybe another interesting project: https://www.ory.sh/ AFAIK NO
| SSO here...
| fasteo wrote:
| Maybe Off-topic.
|
| Any product supporting API Keys (ala github personal access
| tokens) out of the box ? In our case, we are only interested in a
| service to service scenario.
|
| A couple of examples that don't:
|
| Keycloak requires some coding to achieve it [1]
|
| Auth0 does not seem to support it [2]
|
| [1] http://www.zakariaamine.com/2019-06-14/extending-keycloak
|
| [2] https://community.auth0.com/t/how-to-implement-api-keys-
| usin...
| qbasic_forever wrote:
| I really liked Expresss API Gateway, a middleware for express
| that gives a nice API for creating and using auth tokens:
| https://www.express-gateway.io/ It can act as a proxy to
| downstream services and secures access to them with those
| tokens.
|
| Also check out bigger players in the API gateway space. Kong,
| Krakend, etc. Most of them all support auth tokens out of the
| box in the open source versions.
| BinaryArcher wrote:
| As with Keycloak, Auth0 can implement access tokens via a
| client and some code.
|
| However, that would assume you use a custom policy within your
| token for access control, as Auth0 does not provide the same
| level of RBAC for clients as it does to users.
| propter_hoc wrote:
| Is this a viable alternative to Auth0/Okta?
| James-E wrote:
| One of the Authelia devs here. Not yet as we currently are not
| a OIDC provider. However this is a feature we are prioritizing,
| and forward auth / auth request are viable alternatives for
| apps that have any RBAC or support a user/group header.
| DigitalSea wrote:
| I had to do a double take on the name. I thought it was
| referencing the open-source Javascript framework Aurelia.
| 0xbadcafebee wrote:
| _However, Authelia..._ is not an OAuth or
| OpenID Connect provider yet (planned in the roadmap) is
| not a SAML provider yet. does not support authentication
| against an OAuth or OpenID Connect provider yet. does not
| support authentication against a SAML provider yet. does
| not support using hardware devices as single factor. does
| not provide a PAM module yet.
|
| _oauth2_proxy_ is a great tool that lets you create a transparent
| OAuth proxy to provide SSO for any internal service. Protect an
| entire subdomain of services using one identity provider! Guides
| exist for integrating it with K8s, but luckily it 's just a
| binary so you can protect non-K8s services with it too. It's also
| super easy to deploy, as you can configure the whole thing with
| just environment variables, or a config file. The docs are decent
| too. https://github.com/oauth2-proxy/oauth2-proxy
|
| There's also S.S.Octopus, and Pomerium.
| https://github.com/buzzfeed/sso
| https://github.com/pomerium/pomerium
|
| They all have different OAuth providers, so check them each out
| to see which one works with your identity provider. (GitHub OAuth
| + SSO makes using these a no-brainer)
|
| For just SAML, there's saml-auth-proxy, though I haven't looked
| into it much. https://github.com/itzg/saml-auth-proxy
| swiley wrote:
| The Readme only mentions docker for deployment. Docker is awesome
| but when there's no way to use the software without it that's
| always disturbing.
| 0xbadcafebee wrote:
| _" Authelia can be installed as a standalone service from the
| AUR, FreeBSD Ports, or using a Static binary, Docker, or
| Kubernetes. Assistance to publish a debian package would be
| greatly appreciated."_
| James-E wrote:
| One of the Authelia devs here, we support a variety of methods
| of deployment as mentioned by a user below and include a
| systemd unit. If there is any deployment scenario you feel
| we've not accounted for that you prefer then we'd be more than
| willing to look at implementing it.
| qbasic_forever wrote:
| Containers run on lots of non-Docker runtime environments. You
| can just install runc, or if you have systemd you can use
| systemd-nspawn. Or if you want a more Docker-like experience
| there's podman. Or if you're working with it kubernetes and
| containerd will run containers.
|
| And if you don't like any of that, look in the Dockerfile and
| replicate the setup on your server. IMHO in 2021 it's not worth
| someone's time to worry about the eccentricities of 20-30 year
| old bespoke unix/linux distributions and their myriad of
| incompatible decisions.
| koblas wrote:
| This was interesting up until I found this line in the
| documentation. Which is having authentication based on cookies is
| a non-starter for many organizations at this point.
|
| > Authelia relies on session cookies to authenticate users. When
| the user visits a website of the protected domain example.com for
| the first time, Authelia detects that there is no cookie for that
| user. Consequently, Authelia redirects the user to the login
| portal through which the user should authenticate to get a cookie
| which is valid for *.example.com,
| mooreds wrote:
| Setting cookies like that is a pretty standard SSO technique
| for the web as far as I know.
|
| Is there a superior alternative I can read up on?
| donatzsky wrote:
| 1. Do authentication on auth.example.com
|
| 2. Set a session cookie for auth.example.com
|
| 3. Redirect to app.example.com/?token=12345
|
| 4. Exchange token for a session cookie on app.example.com
|
| This way each (sub)domain will have it's own unique cookie.
| mooreds wrote:
| Ah, so the issue is that the cookie was set for the entire
| domain, not that a cookie was set at all.
|
| My misunderstanding. Yes, what you lay out makes sense.
| donatzsky wrote:
| Reading his other comment, koblas was actually talking
| about bearer tokens.
|
| Not sure how they are actually better than cookies,
| though. Certainly can be a lot more complex. With cookies
| you mostly just have to avoid the *.example.com foot gun.
| mcovalt wrote:
| Why is cookie based auth a problem?
| cdjk wrote:
| The *.example.com cookie is the problem. A malicious
| subdomain under example.com will get that cookie and can use
| it to impersonate users.
| XCSme wrote:
| How else do you suggest to store persistent login data?
| koblas wrote:
| Authentication: Bearer headers
|
| This avoids most cross site scripting attacks
| donatzsky wrote:
| Are we talking jwt-style bearer tokens? They have their own
| issues.
|
| Better to have the auth server issue a single-use token
| that gets exchanged for a properly scoped session cookie on
| the app (sub)domain.
|
| Edit: Of course, then you also need some sort on central
| session storage, to properly deal with logging out.
| XCSme wrote:
| But where do you store those? Those have to be sent with
| each request.
| 411111111111111 wrote:
| These are usually really short lifecycle, so they're
| usually just saved in a variable or session storage.
|
| A refresh often just gets a new one, as they're usually
| valid for 5 mins or even less.
| WanderWonder wrote:
| Why Open Source? Paragraph 1 "in the face of* the battlefield"
|
| Definitely on the side of open source when it comes to security.
| But not because it lends itself to cheaper solutions but because
| it allows you to be sure your not being siphoned for corporate
| profit.
| mooreds wrote:
| > it allows you to be sure your not being siphoned for
| corporate profit.
|
| As someone who works for a company which sells an auth
| solution, I'm curious what you mean by this?
|
| Are you concerned about your data being aggregated and sold?
|
| Are you concerned about lock-in?
|
| Are you concerned about security CVEs being hidden or remaining
| unfixed?
|
| Would love to know more.
| lmeyerov wrote:
| as soon as you want to enable users to self-host, esp on-
| prem/airgapped, any internet dependencies, unscannable code,
| etc, will fail basic env and security reqs.
|
| In general, also loses control, which is a risk, and for
| technically unnecessary reasons, elevating that to
| radioactive. provide both oss and paid hosting, and becomes
| fine.
| mooreds wrote:
| > as soon as you want to enable users to self-host, esp on-
| prem/airgapped, any internet dependencies, unscannable
| code, etc, will fail basic env and security reqs.
|
| Hmmm. My employer has people who have used our commercial,
| closed source, self hosted auth software and obtained PCI
| compliance. I'm not a security expert, but my understanding
| is that is a relatively rigorous security process. Am I
| incorrect?
|
| > provide both oss and paid hosting
|
| How do you deal with the "Amazon/GCP/Azure takes the OSS
| software and cross sells it to their customer base"
| problem? This is something I've been thinking about for
| years and years.
|
| Not that this is your problem to solve :) and I get that as
| a customer of a software business one typically doesn't
| care, but thought I'd ask.
|
| One answer I've heard is "be better at running your
| software than AWS" which makes sense, but doesn't address
| cross selling. AWS doesn't have to be the best at running
| ElasticSearch, they just have to be good enough because
| they own a major distribution and payment channel.
|
| Another answer I've heard is "you should be so lucky as to
| have a public cloud pick up your OSS project" which I
| totally understand (obscurity is a bigger competitor than
| the public could for most projects). But it doesn't address
| the very real threat to the business which may arrive just
| when the project can start to throw off profits to pay back
| the initial investment.
|
| Again, I realize there's nuance here and that if a company
| takes the contributions of the community that can
| accelerate their growth and feature set. But I'm just
| curious on your take on the public cloud provider angle.
| lmeyerov wrote:
| self-hosting solves the saas dependency part, which is
| great! saas should be a value add, not a req.
|
| Proprietary & closed source means risk sign-offs and
| having to work w an extra party for sign-offs, so
| unattractive. I'm not sure an auth dependency merits
| that. (And nowadays, a negative signal for security...)
|
| re:business model... I don't know VC-scale ($1-10B/yr),
| but not every infra project has to immediately turn into
| a 10K employee company. That's someone putting their
| global domination ambition over their users, so a sniff
| test for me on a co's management. Maybe there is a way to
| do it, and imo, a $50M/yr co here is totally doable, a
| fine achievement, and can be used to figure out Product
| 2. As an infra user, esp with our own users having us
| make high-trust decisions for things they don't really
| understand, I prefer adding dependencies to projects I
| don't think will do a quick flip / flameout / sell me out
| / etc.
| mooreds wrote:
| Thanks, definitely appreciate the perspective and
| thoughtful answers.
|
| I don't think that worries about a cloud provider eating
| the lunch a company has set (to get metaphorical on you)
| is solely limited to VC funded companies, but I do
| appreciate they're more likely to worry (see
| ElasticSearch, of course).
|
| > but not every infra project has to immediately turn
| into a 10K employee company.
|
| Couldn't agree more!
|
| Cheers!
| lmeyerov wrote:
| Also, I'm not sure I buy the concern about aws & friends
| in this space for a few reasons:
|
| -- Now that SaaS for identity is established, the natural
| next step is OSS versions that come with SaaS, so if
| you're starting fresh and know that's coming... it seems
| short-sighted to start without that
|
| -- aws & friends have their own identity products, so
| given the already-commoditized market, they're unlikely
| to want to be pushing your n+1 one
|
| OSS seems more like a growth driver here than a risk b/c
| of the competitive market, though I can see that being
| unsettling to traditional business/VC types who are out
| of touch with the market. What the value-add for a
| managed layer is seems like "a lot possible", e.g.,
| scale, support, multi-cloud, so I'd expect customers to
| pull you pretty quick if they didn't already.
|
| In our case, quite explicitly, we're evaluating a path
| where on-prem single-tenant users can bundle & self-serve
| something (SSO/LDAP/...), while for our saas tier, we can
| hook into something normal by aws/azure/someone else.
| Lack of full-featured OSS (w/ no SaaS necessary) for on-
| prem, or at least a clear way to let us transparently
| swap something like Keycloak for those folks, is an
| instant no.
| colineartheta wrote:
| Not OP, but, all of the above.
___________________________________________________________________
(page generated 2021-03-10 23:01 UTC)