Remote Authenticator

[jendrikjoe]

Is your feature request related to a problem? Please describe.

We have a system where we do machine requests utilizing RSA singing to validate both, that the message was send by a specific machine and that it didn't get tampered with. For this we take the body, sign it with a private key and add the message signature as a header (we could include it in the body, but would still face the same issue).

On the receiving side we now take the body and the public key and check that the signature is valid. This leads to my feature request: We would like to add an authenticator that allows to just forward the request somewhere else for authentication.

Describe the solution you'd like

The solution we imagine is to just forward the original request and body to another service that can then reply with 200 and 401 and a body containing extras and the subject. It would be somewhat similar to what ambassador has for their extrnal filter.

We as well have an implementation of this we would be happy to contribute, but I wanted to open this issue first to see if we missed another way of implementing this.

Describe alternatives you've considered

We considered using the other authenticators, but as far as I know none of them would allow us to validate the message body wasn't altered.

[jendrikjoe]

As the code is ready on our side, a very polite ping on this 🙂

[jnodorp-jaconi]

Isn't that exactly what the bearer_token authenticator does?

The bearer_token authenticator will forward the request method, path and headers to a session store. If the session store returns 200 OK and body { "subject": "...", "extra": {} } then the authenticator will set the subject appropriately.

[jendrikjoe]

Hey @jnodorp-jaconi, thanks for the response 🙂
Unluckily the bearer_token authenticator only does a subset of what we need.
In the validation we want to check that the signature in the header matches with the message send in the body. However, the bearer_token authenticator does not forwarded the body, only the headers 😉

[jendrikjoe]

Another polite ping 🙂
If it helps, I am as well available under @jendrik in the ory slack channel 🙂
Would be very happy to describe the limitation and our fix for that in more detail or directly open a PR with the changes, if that is of any help 😉

[jendrikjoe]

I am sorry for nagging here, but this is very relevant for us, the code exists and I can imagine that others need this authenticator as well. Could I please get a comment on this? 🙂

[aeneasr]

Hey, sorry about not being responsive at all. Yes, that sounds like a reasonable approach! Looking forward to see your PR :)

I'll be on vacation the next month but I'll try to sneak in a few looks into this :)

[jendrikjoe]

Hey @aeneasr, no worries 🙂 Thanks for coming back and happy that you like the proposal 🎉

Handing over to @vladr11, who implemented this on our side 😉

[github-actions]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️

[jendrikjoe]

Hey @aeneasr , can we remove the stale label on this? 🙂 We still have the open MRs and still think that it would be a valuable features 🙂

[github-actions]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️