Hacker News Reader

Where is the ORY Security Console hidden? I can't see it on GitHub and all links lead to a running instance of it?

Is this how you're hoping to monetise all your hard work? I don't begrudge that at all :-) It's just a little unclear?

If there's going to be a security console, I wouldn't want it hosted by anyone else. Especially if I'm the type of person to deploy all the other components I'll undoubtedly want to deploy the console myself.

[EDIT] There's also some on by default telemetry.. and the link for details is 404'ing: https://github.com/ory/oathkeeper#telemetry -> https://www.ory.sh/docs/guides/latest/9-telemetry I might not mind this, but I can't tell if the links don't go anywhere.

I don't want to sound negative, other than these queries the ORY ecosystem looks lovely and something I might implement.

Cheers

Thanks for bringing this up, I would not have looked for it.

anything regarding this? Would also be interested if you plan releasing the console, i.e. allow a fully self-hosted usage.

I really like this suite of projects, it splits the problem nicely into flexible building blocks.

How do you envision integration of existing external OAuth2 or OpenID Connect servers, such as Google, GitHub, etc., or an OAuth2-compliant directory of a B2B customer?

We're currently starting to work on ORY Hive (project name wip) which is going to be a fully functional identity management service (user registration, login, social sign in, password reset, MFA, ...) sort of along the lines of Auth0 or AWS Cognito, but as an OSS solution.

As part of that service, we will add connectivity adapters for generic OAuth2/OIDC providers as well as (probably) LDAP/AD and SAML integration.

We're still in prototyping phase (building a good API here is really tricky because no open standards exist to our knowledge for this) and it will take some time. But hopefully, it will be something many people can build on!

And thank you so much for the positive feedback :)

Thanks for the info, looking forward to your new project!

That sounds awesome! I'd really like to see organizational management, i.e., users in orgs. It is something most B2B SaaS apps have to do, and they tend to do it differently and often very poorly. Maybe it is out of the scope of ORY Hive, but I think it would be really useful. I'm thinking it would tie into an RBAC system to give users different permissions within orgs (member, admin, owner, etc.).

There are two main patterns for B2B apps:

- One org per user, like G Suite. A user is a member of a single org, to be a member of another org requires another user account. This creates a challenge when it is a system where someone might be a member of multiple orgs, because it requires logging in as multiple users and having cookies that can handle that.

- One user in many orgs, like GitHub. A users "owns" their user account, and is invited to one or more orgs. This makes working in multiple orgs easier, but can create challenges for companies that want to enforce things within their org, like SSO or 2FA. It also creates issues with routing of notifications (you want work notifications going to work email), and identity of users within a company (an org admin may have trouble identifying users if they aren't tied to company emails).

An ecosystem like ORY obviously can't alleviate all the issues, but maybe it can help with some of them, like org membership and org friendly cookies.

Good use cases, we in fact are looking at multi-tenancy or "realms" but have not progressed very far here as it can get quite complicated. One major issue with true multi-tenancy is obviously data isolation, so usually you don't want data to "bleed" from tenant a to tenant b (think G Suite) whereas in other systems it's not truly a tenant but more of a business entity that shares users.

I think in the end it boils down to what we can solve in a generic manner and what we can let developers solve for themselves. The distinction between the two use cases is definitely something we'll take a closer look at and include in our design decisions, so this won't be an afterthought but something built into the architecture!

Thank you for your constructive feedback!

This is a cool project, I'll definitely keep an eye on it. I've long wished that something framework & language agnostic like this existed.

One suggestion for the docs, especially since the tagline is that this is a cloud-native solution, would be examples of how to run it in common cloud setups. For instance I'm looking at the deployment page and it mentions that in the gateway configuration you'll want to run it behind a load balancer but in front of the API router. But if you're using an ELB, which as far as I'm aware is still part of basically the default way to run web apps on AWS, the load balancer and router are combined and there's no way to hook something like this in. So it would be cool to see some examples involving specific tools like ELBs, maybe a note on other ways to run it if using Kubernetes, etc.

That's a really good point! I've tracked this as https://github.com/ory/docs/issues/29

We're a very small team, so it might take a while for us to tackle this (especially because we mostly use k8s with oathkeeper proxy as a sidecar), but that does make this not lesser of an issue!

Can ORY Hydra connect to an LDAP (AD) backend? We've got SAML setup here but I'd love to be able to support OpenID Connect too.

Yes, ORY Hydra has a flow that allows you to integrate with any identity solution, be it AD/LDAP, SAML, or your custom database-backed app!

This solution seems comparable to running Envoy Proxy as a reverse / frontend proxy with a JWT filter. Would you say that's a fair comparison? What would you say are the benefits of using this over such an Envoy setup with Envoy becoming so popular?

Super excited to see more players move in this space btw!

I have not used envoy extensively yet, but there are obviously many more options such as Apache2 + mod_oidc, Kong + oauth2 plugin, and so on.

The main differentiator is that Oathkeeper is capable of performing more sophisticated permission checks (think RBAC / AWS IAM Policies) and is specifically geared towards solving authentication and authorization in front of "your" service.

Most other implementations I saw (and I think this also goes a bit for envoy) is that they solve access control as one of the things in the feature set, while also focusing strongly on routing, load balancing, and other typical API gateway issues.

We're explicitly not trying to build another API gateway but instead something that you deploy alongside your existing API gateway (or maybe as a sidecar) with the sole purpose of checking answering: "is the request that's coming through really allowed to perform that action?".

Hope this clarifies it, if not I'm more than happy to go into more detail :)

Seems like you are describing Ambassador here [0]. I think this could play nice as Ambassador's external auth service [1].

Oathkeeper looks very interesting... Congrats and best of luck!

[0] https://www.getambassador.io

[1] https://www.getambassador.io/reference/services/auth-service

Nice, I have heard about Ambassador before but did not have the time to look into it in detail. It is just amazing how much OSS is being created around the k8s/container ecosystem and I truly believe that it will greatly improve our lives as developers in the future.

I've added this to our internal list and we will check it out and see if any synergies are possible with our products. Our vision is that these services work so well and easy with the rest of the ecosystem, that you can get started with a new project in a day or two and have everything set up - from users, to permissions, to routing (e.g. via ambassador), to testing (there's still ton of space for this), and so on.

I think the journey of software development beyond 2020 will be very exciting!

ps: Sorry for slow responses, HN has a very high post wait time once you hit the limit. And thank you for the positive vibes :)

I was just speaking with Datawire/Ambassador CEO in their slack about Oathkeeper... you should reach out and speak with them. Interesting synergies IMO.

Awesome, following up in their slack :)

Check out CNCF's Interactive Landscape to keep track of the ecosystem: https://l.cncf.io

That's an awesome list, thank you!

> solve simple and complex IAM

really great. please comment on the intersection with auth0. clearly there is some overlap, it would be great to have a concise explanation.

> we do not want to reinvent the wheel

IMHO, were I you I would not shy away from that. Existing wheels are oval in shape. Of course where you have to interoperate, you are limited.

> ps: New account because I lost my password and didn't set up a backup email. Stupid me.

Well you just lost me. You are developing IAM components and you can't get basic password management correct? email has nothing to do with it, we are well past the point where password managers are de rigueur, certainly for anyone involved with security matters.

> Well you just lost me. You are developing IAM components and you can't get basic password management correct? email has nothing to do with it, we are well past the point where password managers are de rigueur, certainly for anyone involved with security matters.

The password in my password manager is not correct. No idea how that happened, maybe it was overwritten by accident or I copied the wrong one during account creation. Since I had to reset my FF profile it was no longer stored in the FF password manager, so I had to recover it from KeePass, which well - didn't work out so well. Since I do use a password manager, it's impossible to recover it as I have no idea what the password is.

A bit extreme don't you think ? He's human and people lose access to old accounts from time to time...

Has nothing to do with the fact he's developing auth software.

Besides, HN does not do oauth. If it did and he would still lose access then it's a different story ;-)

Getting the wrong password in your password manager happens occasionally. Usually from password resets that somehow don't make it into your password manager. The fact that HN allows accounts without email addresses is the real problem. Also, maybe he just doesn't value his HN account all that much.