OAUth 2 Authentification

[Loïc MATHIEU]

Hello,

As I understand it, Quarkus is able to authenticate a user based on the following mechanisms:

- Basic Authentication based on users in a file (or in application.properties)

- JWT token

- Keyclock (that allow multiple authentication methods)

So there is not way to authenticate a user in Quarkus based on OAuth2 without JWT. It's a very common use case that an existing authentication server exist (so using Keycloack is not an option) and that this authentication server is used without JWT (for example for basic use case of API authentication based on client_credential flow).

As I need this functionality for the application I am currently working on, I implemented it.

I think there is a real interest in integrating it in Quarkus, if others think so we can start discussing about the integration.

My current implementation adds an authentication mechanism in the existing quarkus-elytron-security extension that use the Undertow TokenSecurityRealm so it's not a very complex integration.

Regards,

Loïc

[Sergey Beryozkin]

Hi

How generic it is going to be if a token is a DB pointer/etc ?

Cheers, Sergey

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
Visit this group at https://groups.google.com/group/quarkus-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAJLxjVFn0Gr1X4si%3DaqYM-9a1sw7uQNpCCqgPsG%3DTrAHcoZ2YQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Loïc MATHIEU]

My implementation uses the introspect endpoint to gather user information from the authentication server as defined in http://docs.wildfly.org/14/WildFly_Elytron_Security.html#validating-oauth2-bearer-tokens.

It uses the username claim (or the client_id if none found) for the username and extarct the roles from the scopes.

But I'm agree that Quarkus authentication should have a way to allow users to hook into the authentication mechanism to provide there own identity provider : provide a way for a developer to extract the user information from whatever they want (DB, LDAP or a token as I did). This can be a good addition to Quarkus.

[Sergey Beryozkin]

Having an Elytron based mechanism in Quarkus for validating non-JWT tokens via a standard introspection endpoint would be good IMHO and is generic enough.

Note there is also a smallrye-jwt issue to validate JWT tokens via the same mechanism:

https://github.com/smallrye/smallrye-jwt/issues/32

It is a bit unfortunate that MP JWT is about JWT tokens only but I guess the spec can be relaxed a bit.

Once this issue is done (and Quarkus is updated to support the custom factories), one would get even a binary token accessed via MP JWT Api (some properties can be nearly the same).

However a simple Elytron based solution may work well too

Sergey 

[Luca Masini]

Hi Mathieu, what about pushing all the informations inside the JWT Token ?

We are integrating Ping Identity this way, Ping integrate with AD, extract user-infos and populate JWT claims.

Can be a solution for you ?

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAMsYBfWyk375FpaQ8Qtb6CHgk5a09iHOTh3n9OHF6mcUxuGWGQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

****************************************
http://www.lucamasini.net
http://twitter.com/lmasini
http://www.linkedin.com/pub/luca-masini/7/10/2b9
****************************************

[William Burke]

We should probably derive from the keycloak oidc client adapters and even contribute back to them.  OAuth2 has some tricky points to it that you want to get right.

BTW, I thought Elytron was more of a framework to propagate and inject Principals and authz information rather than something you should build protocol adapters on top of.  

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAG%3D-wFPv6AV-V3_wnerv3OcC6uhhBu1Sgr9m%3DLjP%3Da5wp-2bLw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Bill Burke

Red Hat

[Luca Masini]

Hi Bill, I opened two thread about this some time ago:

https://groups.google.com/forum/#!msg/quarkus-dev/t41FGjNfC80/Si_lIul7AgAJ

https://groups.google.com/forum/#!msg/quarkus-dev/FMgq7ZeYaWw/2hesQRclAgAJ

if you have time to read them consider if we are thinking the same, I think so.

Bye

To unsubscribe from this group and stop receiving emails from it, send an email to quark...@googlegroups.com.

Visit this group at https://groups.google.com/group/quarkus-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAJLxjVFn0Gr1X4si%3DaqYM-9a1sw7uQNpCCqgPsG%3DTrAHcoZ2YQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to quark...@googlegroups.com.

Visit this group at https://groups.google.com/group/quarkus-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAMsYBfWyk375FpaQ8Qtb6CHgk5a09iHOTh3n9OHF6mcUxuGWGQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

****************************************
http://www.lucamasini.net
http://twitter.com/lmasini
http://www.linkedin.com/pub/luca-masini/7/10/2b9
****************************************

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.

To unsubscribe from this group and stop receiving emails from it, send an email to quark...@googlegroups.com.

Visit this group at https://groups.google.com/group/quarkus-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAG%3D-wFPv6AV-V3_wnerv3OcC6uhhBu1Sgr9m%3DLjP%3Da5wp-2bLw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Sergey Beryozkin]

Enhancing the Keycloak adapter to validate the 1) non-Keycloak (and 2) possibly binary) tokens would be nice indeed, I opened a Quarkus issue for 1). I have a couple of smallrye-jwt issues to support such cases in case it would be difficult to do so with KC alone.

Would be good to address them as part of the security consolidation story IMHO, so that the users can combine KC and smallrye-jwt easily without having to choose between the two...

Cheers, Sergey

To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

Visit this group at https://groups.google.com/group/quarkus-dev.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/a98c36e3-1235-4791-93b5-3849f9e83476%40googlegroups.com.

[Sebastien Blanc]

+1

In the coming weeks , I will have some free cycles dedicated to the security consolidation story. These are items that we need to discuss. 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAMsYBfW9rG%2BOP-XfbbkNnniZM7JsPZvsxB62WqDizHEbPyY9LA%40mail.gmail.com.

[Loïc MATHIEU]

Hello,

I made a small prototype of what I have in mind : I add a new auth mechanism in the existing elytron-security extention, based on the wildfly-elytron-token-bearer library, that take a bearer token and use the introspection endpoint to validate it and extract the user information. 

I map the user information this way :

- username : a username claim in the introspection JSON response or the client_id (in the case of client_credential flow)

- roles from the scopes

You can find the code here : https://github.com/quarkusio/quarkus/compare/master...loicmathieu:feat/oauth_provider

Tell me what you think about this ?

Regards,

Loïc

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAD_dpu0pFw5YX3MTmNzoAKTA1_d_eX%3DCS7kNBLLVQKhoHo5vuQ%40mail.gmail.com.

[Sergey Beryozkin]

Hi

IMHO it is a good start (the custom principal should optionally expose all the other introspection response details), but I guess the dilemma would be that if there a case of a Keycloak JWT token coming in then this solution will probably also work (I guess if you configure it to point to the KC introspection endpoint), so the users would have a choice of 3 solutions, 1) this one 2) KC adapter 3) smallrye-jwt (once it supports the introspection).

Hopefully over time 2) and 3) will be seen as a single solution (in case of the Keycloak tokens, KC adapter does the validation, and MP JWT API is used to access the tokens from the user code).

What I'm not 100% sure about myself, what happens when smallrye-jwt will also support the token introspection, it is a straightforward enough issue to fix and it is needed for the MP JWT users IMHO. And say we have a binary token from a 3rd party provider which the KC adapter can not validate but this provider offers a token introspection endpoint.

So we will have 2 solutions, the elytron based one and another one where a token (which may not be even JWT) is effectively mapped to JWT at the smallrye-jwt level from the token introspection response.

(and https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-01 is the industry step in this direction I guess)

I suppose this is another situation which would need to be discussed as part of the security consolidation story

Cheers, Sergey

[William Burke]

OIDC rather than OAuth should be targeted.  They already have a lot of these protocols defined and implemented cross-industry wide.

MP JWT should really be broken out into separate extensions.  A claim mapping extension (really anything that defines integration with the component layers) and the authentication layer.  That way Keycloak can replace the authentication layer and doesn't have to worry about claim mapping.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAMsYBfUF44jU%2BbdUU0_Kf7SiHgsDDdXXSzX%3D4barUKqYj4%2Bgwg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Sebastien Blanc]

+1 love that idea Bill ! 

[William Burke]

Actually I don't think you'd need separate extensions, MP JWT extension would just need a mechanism to turn of its default authentication.  i.e. it could just look for a marker BuildItem and not wire in the defaut implementation if that exists.  Keycloak would just publish that marker BuildItem.  This is an implementation detail though.

[Loïc MATHIEU]

Hello,

OIDC is a good thing but sometimes we just want tu use plain OAuth2 without JWT nor OIDC (this is very common for server to server authentication in a microservice architecture where one API access another one).

And for this, there is no solution yet in Quarkus.

Both keyclock and JWT extentions are today bind to there protocols, and comes with a lot of dependencies (I counted 10 at least for keyclock without counting Jackson, and 11 for JWT).

My addon to the elytron-security extention just add one small library (wildfly-elytron-realm-token) that contains a few classes.

Moreover, both keyclock and JWT extention should be able to reuse some of it's components, we can refactor later the three implementation to use a common Principal/Credential based on JSON claims ..

I'm agree that the security components of Quarkus needs some refactoring to be able to covers more usecases (I can share some ideas about this, we need at least a way for the user of Quarkus to provide there own identity manager on top of existing protocol), but I would really love to have the ability of making bare OAuth2 authentication flow as my proposal provides.

So, can I propose a PR with my changes inside the elytron-security extention (or in a separate extention)? Or do I need to wait for an other solution ... or create an extention outside Quarkus ? As I really need this asap (I choose Quarkus for a new project and I assumed that OAuth2 is covered as it seems basic to me and JWT is covered ... but it isn't so I'm a little in trouble ...)

Regards,

Loïc

[Sergey Beryozkin]

Hi Bill

smallrye-jwt (MP JWT) has not been designed to support the OIDC or Oauth2 based flows in general, its 'spec' (for now at least) is about validating the token and making the authorization decision and if the token is not available or valid then the immediate HTTP 401 or 403 is all what can happen.

So yes, optionally turning off its authentication mechanism and instead only 'extend' the KC adapter's one by offering an MP JWT API to work with the tokens would be good.

As I mentioned, there are few issue in smallrye-jwt to support the cases where the tokens are coming for example from Ping Identity or it is not JWT, and for whatever reasons the KC adapter itself can not handle it.

In Quarkus:

https://github.com/quarkusio/quarkus/issues/2287

(created awhile back)

and

https://github.com/quarkusio/quarkus/issues/3064

(just now), both issues have a new 'security-consolidation' label.

in smallrye-jwt:

https://github.com/smallrye/smallrye-jwt/issues/41

(I'm not very keen to go this route but smallrye-jwt is not only for Quarkus so some basic support may be needed in cases where the KC is not available or even when it is available but it can't deal with the non-KC tokens as it is the case now)

and

https://github.com/smallrye/smallrye-jwt/issues/32

(simpler cases where the validation alone is sufficient)

Cheers, Sergey

[Sergey Beryozkin]

Hi Loïc

If all what you need is to validate the token then it does not really matter how did it reach the service, as part of some OIDC or simpler OAuth2 flow or was self-issued by the client, because all the service can do in the case of the invalid token is to respond with the HTTP failure.

I'd encourage you to go the smallrye-jwt way once it is available (it would introspect the token and map it to JWT).

Your proposal still makes sense for the simple cases where the users don't need more than a Principal.

I'm not sure if everyone agrees but I'd suggest going ahead with the PR (I think it should become a standalone extension though, -elytron-oath2 may be, so that the smallrye-jwt users don't have to pull it in, as well for the existing elytron one not having to have a specific code about the specific type of the authentication).

My concern is what would Quarkus recommend to the users when both elytron and smallrye-jwt cases would be able to achieve the same for such cases. But it can be discussed further I guess...

Sergey

[Loïc MATHIEU]

Hi Sergey,

OK, I will extract the code in a separate extention and open a PR.

Regards,

Loïc

[Sergey Beryozkin]

Hi Loïc

Sounds good (please note I can't guarantee it will be accepted but but lets do it and see what happens :-) ), and your effort may encourage me do better with the related effort in smalltye-jwt :-)

Cheers, Sergey

[Loïc MATHIEU]

Hi Sergey,

No problem, if it isn't accepted, I will distribute it on my own github in case someone else needs it ..

Regards,

Loïc

[Darran Lofthouse]

On Sat, Jun 29, 2019 at 1:33 PM William Burke <bbu...@redhat.com> wrote:

We should probably derive from the keycloak oidc client adapters and even contribute back to them.  OAuth2 has some tricky points to it that you want to get right.

BTW, I thought Elytron was more of a framework to propagate and inject Principals and authz information rather than something you should build protocol adapters on top of.  

It does provide the mechanism SPIs as well although I don't believe these are in use within Quarkus yet.  We also have some examples re-using mechanisms now across Jetty and Netty independently of Undertow APIs.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/CAL%3DE%3DjSWz0QwYrYpMNtc8FhUD4b%3DnOMzAxvnSwAzaoYBTuqEgA%40mail.gmail.com.

[Loïc MATHIEU]

Hello,

As discuss with Sergey, I create a PR: https://github.com/quarkusio/quarkus/pull/3078

Discussion is open whether or not it should be included in Quarkus (I strongly support it's inclusion, but I'm biased as I write it and need it).

Regards,

Loïc

[Sergey Beryozkin]

Hi Loïc

It occurred to me that the same idea that Bill suggested to have the smallrye-jwt recognizing that KC adapter would prefer to authenticate would work for your proposed extension as well, so it would (in a would be follow up PR) create a build item marker, get an introspected token info, and check for a Principal provider (while smallrye-jwt would disable its auth mechanism after recognizing the marker and offer a principal provider which would convert the introspection info into the JsonWebToken, something like that).

The only preference I have right now is to have this extension named similarly to the related wildfly component, -elytron-realm-token may be, as '-oauth2' is not really precise, your extension would work for any token really (OIDC issued as well) as long as the issuer offers an introspection endpoint.

Let me comment on your PR soon

Cheers, Sergey

[1] https://github.com/quarkusio/quarkus/issues/3064

[William Burke]

BTW, is anybody else concerned that MP JWT defines some new claims?  At least from Keycloak experience, many many apps have to be developed in an existing security model.  Many IDPs won't be able to publish these new claims.  I think MP JWT might be better off making the principal claim and groups claim configurable...Or better yet, just write a JAX-RS filter that defines a new SecurityContext implementation.

[Sergey Beryozkin]

Hi Bill

We opened an issue the other day:

https://github.com/eclipse/microprofile-jwt-auth/issues/129

but since then the smallrye-jwt library itself has been enhanced significantly to take care of different custom variations.

The roles to groups mapping can be easily done (example, a KC token containing a non top level roles claim can have it mapped, though as Loic reminded me separately I forgot that 'scope' has the roles inlined, minor issue though).

As far as the principal name is concerned, MP JWT does quite well, it checks 'sub' and 'preferred_user_name' as well as its own 'upn' (in the reverse order) but after working with Roberto, we can now have smallrye-jwt mapping some custom claim into the 'sub' and thus into the Principal name, though this can be further generalized I guess.

MP JWT Claims enumeration has quite a few claim names I've never heard before of, but with the MP JWT targeting the tokens from all sort of origins it could be explained why they made it into that enum...

Sergey