Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to handle Authorization #53

Closed
bigwheels16 opened this issue Mar 8, 2019 · 12 comments
Closed

How to handle Authorization #53

bigwheels16 opened this issue Mar 8, 2019 · 12 comments
Assignees
Labels
discussion Discussion about features

Comments

@bigwheels16
Copy link
Contributor

bigwheels16 commented Mar 8, 2019

Currently I have several apps running behind Apache using the mod_auth_openidc module that is configured to delegate authentication to Auth0, which is configured to delegate to Google. So technically anybody with a Google account can successfully authenticate. However, there are only a few users that should actually be able to access these apps. The mod_auth_openidc module I am using lets me restrict access to only users that have specific claims in their id token, and using Auth0 rules (I am using the Auth0 authorization plugin) I can make sure those claims are only added for the users that I want to allow access.

Does this project have a way to achieve something similar to that? Or any plan or desire to add that?

I am not necessarily looking for the same mechanism that the Apache module uses, but just some way to centrally manage and control authorization to services behind Traefik on a per-service and per-user basis.

@dniel
Copy link
Owner

dniel commented Mar 8, 2019

Use Auth0 to perform authorization logic.
Auth0 "provide a universal authentication & authorization platform for web, mobile and legacy applications." as they say. Auth0 is very flexible on how to implement authorization.

You could for example use Rules to create simple authorization logic, or you could combine Rules and the Authorization Extension to create a more complex logic.

@dniel
Copy link
Owner

dniel commented Mar 8, 2019

If you already have authorization logic in Auth0, why not also block access with rules in Auth0 at the same time?

@dniel
Copy link
Owner

dniel commented Mar 8, 2019

I checked how ForwardAuth handle when Auth0 responds with error=unauthorized
Seems that it just bugs out with standard error handling #54 when it should have handled this nicer.
I'll have to fix that.

@bigwheels16
Copy link
Contributor Author

Hmm, I guess I had never considered that. I'm not sure how I feel about that considering this is an authorization concern and that would effectively be moving it to an authentication concern, but I'll give it a try and see how it works out.

@bigwheels16
Copy link
Contributor Author

So I did get this to work by writing a rule in Auth0. In a simple scenario, it works fine, but it's probably not sufficient for slightly more complex scenarios.

For instance, let's say I have app1.mydomain.com and app2.mydomain.com. And then in Auth0 I have rules about who can login based on which app they are trying to access. In the simple scenario, I set the cookie domain to app1.mydomain.com and app2.mydomain.com, respectively, and then I have to login once for each app I want to access. So far so good.

Let's say that I decide that I don't want to have to login separately for each app. So I set the cookie domain to mydomain.com. This way I can login once, and then access all the apps. And as long as access is all or nothing, all apps or no apps, the current setup works. But if I want to give a user access to app1 but not app2, this won't work anymore because he could just login with app1, and then from there access app2.

It would be ideal, and also idiomatic OAuth2, to require a certain a "scope" in order to access a particular app. For instance, the "app2:read" scope might be required to access app2.mydomain.com.

So I am suggesting an enhancement where you can specify a list of required scope within the yaml configuration that would grant access to the app (see the last two lines in the example below). If this is something you are open to, I'd be willing to submit a PR with the changes, but I'd probably need you to point me to the place in the code where the check should go.

 domain: https://mydomain.auth0.com/
 token-endpoint: https://mydomain.auth0.com/oauth/token
 authorize-url: https://mydomain.auth0.com/authorize
 
 default:
     name: mydomain.com
     client-id: <CLIENT_ID>
     client-secret: <CLIENT_SECRET>
     audience: https://mydomain.com
     scope: "profile openid email"
     redirect-uri: https://mydomain.com/oauth2callback2
     token-cookie-domain: mydomain.com
 
 apps:
   - name: whoami.mydomain.com
     redirect-uri: https://whoami.mydomain.com/oauth2/signin
     token-cookie-domain: whoami.mydomain.com
     required-scopes:
       - whoami:read

@dniel
Copy link
Owner

dniel commented Mar 14, 2019

Yes, actually I have considered this solution as well but I have not implemented enough advanced rules in Auth0 to test it out yet. I agree that it would follow a correct oauth2 design in theory. I willl give you some guide to the code where such checks should be implemented later today.

@dniel
Copy link
Owner

dniel commented Mar 14, 2019

@bigwheels16 The authentication and authorization checks should be added to this method: https://github.com/dniel/traefik-forward-auth0/blob/master/src/main/kotlin/dniel/forwardauth/application/AuthorizeCommandHandler.kt#L49-L68

This code that actually does the redirection based on the authorization and authentication result above is here: https://github.com/dniel/traefik-forward-auth0/blob/master/src/main/kotlin/dniel/forwardauth/infrastructure/endpoints/AuthorizeEndpoint.kt#L35-L61

New properties in the configuration file must be added to this class
https://github.com/dniel/traefik-forward-auth0/blob/master/src/main/kotlin/dniel/forwardauth/AuthProperties.kt and to make inheritance of values from the "default application" happens here https://github.com/dniel/traefik-forward-auth0/blob/master/src/main/kotlin/dniel/forwardauth/AuthProperties.kt#L53-L68

@bigwheels16
Copy link
Contributor Author

ok thanks, I hope to start looking at this today

@dniel dniel added the discussion Discussion about features label Mar 26, 2019
@bigwheels16
Copy link
Contributor Author

So I started working on this but I had to stop to finish a project. But I hope to be able to finish it soon.

@dniel
Copy link
Owner

dniel commented Apr 4, 2019

@bigwheels16 no stress, I appreciate your help a lot :)
Whats really nice news is that two different homelab discord groups has reached out this week and started using the application and if we add features they need and fix the bugs they find we have a nice group of users, and I hope they can contribute with testing, html, documentation. Not sure how many they are, but they are really enthusiastic and motivated. :)

@bigwheels16
Copy link
Contributor Author

@dniel Hi Daniel, I really wanted to work on this and also learn some Kotlin at the same time, but my priorities have changed and I don't see myself getting back to this for a while unfortunately. So if you want to close this issue, that is fine.

@dniel
Copy link
Owner

dniel commented Jun 4, 2019

@bigwheels16 No problem! Thanx for the update :)

@dniel dniel closed this as completed Jun 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discussion about features
Projects
None yet
Development

No branches or pull requests

2 participants