MP-0005 JWT RBAC

[starksm64]

Proposal for a MicroProfile specification

! DO NOT MERGE this Pull Request BEFORE REVIEW is finished!

Merging this Pull Request means that the proposal is officially accepted by the MicroProfile Core Team as a MicroProfile incubation project. A public discussion and an agreement within the MicroProfile Core Team is expected before a proposal is accepted/rejected.

If this PR is not a proposal for a new specification, delete this template description.

Suggested steps to follow before this proposal is accepted

• add label proposal to this PR on github
• initiate a public discussion on the mP mailing list
  • Email Subject: "Review announcement: <<PROPOSAL_NAME>>"
  • Email Body: Based on review announcement template
    • fill in <<PROPOSAL NAME>>, <<REVIEW END DATE>> (not mandatory, can be announced later, but should be at least 7 days after the announcement email is sent)
      and <<REVIEW MANAGER NAME>> (the name of the sender)
    • update the link to a proposal (NNNN-proposal.md) to point to this Pull Request

After the review, the Core Team should form an agreement whether or not to accept the proposal, or whether ask its author for amendments.

Once this Pull Reuest is merged, the proposal is considered accepted and an incubation repository should be created to facilitate collaboration.

[johnament]

• they are (last two words)
• I'm not sure we've defined what MP 1.1 is

[NottyCode]

The content ofr MP 1.1 was proposed on Jan 16th on this thread:

[johnament]

Based on the on going discussions, I think it would be better if each spec removed references to the MP version they're planning to associate to, since it looks like we're going to the big bang EE route and proposing umbrella specs to pull things together.

[starksm64]

Agreed

[johnament]

Are you able to cite this? It seems that both per-request and maintaining session state are used, so I'm not sure we can make this claim.

[starksm64]

It is just the original stateless requirement from Fielding's original work:
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

[johnament]

For the methods here, while we can leverage them, would it make more sense to have a dedicated domain around user that could solve these method calls as well?

[chunlongLiang2007]

1. nonce: The "nonce" claim in ID_Token is unmodified authentication request parameter to mitigate replay attack. How does JWT receiver interpret this claim? Use it as normal "nonce" for replay attack prevention? Do we expect token be reused?
   For JWT, the "jti" claim is commonly used in replay mitigation. Should we suggest "jti" as alternative to "nonce"
2. preferred_username: Comparing to other claims, "preferred_username" is very long. What is the definition and intended usage? How about those names like "upn", or "username", or "user", or "login"? Maybe we should have 2 claims, "user" or "username" or "preferred_name", and "upn" or "principal" or "unique_name" or "uid"?
3. "realm_access": If "role" in "realm_access" is similar or equivalent to the "role" in J2EE security, that represents all service roles that the subject has been granted, why do not we remove "realm_access", and simply use "roles" claim.
4. "resource_access": To me, this claim is more like OAuth "scope". Can you explain the difference between "resource_access" and "scope"?
   We believe that following claims are also very useful
5. "groups": Although "roles" claim represents service roles a subject has been granted, this requires existing service is re-written or packaged in order to use JWT. We believe that we should offer alternative option of "group" claim to allow existing service to map service role to "group". This also allows service to decouple authorization and authentication.
6. scope: allow scope claim in JWT.

[NottyCode]

I think it would be helpful to outline how this would affect the microprofile conference service sample. That has 4 micro services written by 4 different groups on 4 different runtimes, so if we can relate how this would help have a JWT token issued once be available and understood by the individual runtimes and services I think that would help people understand the proposal. Certainly for those of us who are not as familiar with JWT.

[arjantijms]

Existing services that desire to implement JWT RBAC must configure the container to support integration with an authorization implementation that is capable of parsing the JWT bearer token to validate the token and populate a security context with the caller and granted roles for use in getCallerPrincipal()/getUserPrincipal(), isCallerInRole(String)/isUserInRole(String) type of container methods.

The heavy lifting for setting up this context for use in getCallerPrincipal()/getUserPrincipal() etc has been done by Soteria/JSR 375, so by taking advantage of that this task would basically be trivial.

@rdebusscher even did an initial POC for parsing the JWT bearer token and from it populate the above mentioned security context. See https://github.com/rdebusscher/soteria-jwt

[starksm64]

@NottyCode, Ok, I'll write that up.

[rdebusscher]

Sorry to jump into the discussion at such a late point.

I see in the proposal a very good description of the JWT and "protocol" which will be used to communicate the authentication/authorization information to some endpoint.

But will be there a description how the info (username, roles, ...) will be transferred to the "container"?
When using
@Inject private Principal;
there will be access to the username, but not to the "roles".

There was a mentioning of using Soteria/JSR-375 which is mainly a layer on top of JASPIC (and JACC). Going that way, we specify that every MicroProfile compliant server will need those specs. Which is not recommended in my opinion.

[johnament]

@rdebusscher we wont' get into that until the spec starts to get written. proposals are not specs.

[rdebusscher]

Thanks for the clarification about the process.

JWT and the info that was written in the proposal is absolutely fine for me.

[chunlongLiang]

Thanks @johnament for clarification of spec process. We are good for the proposal to start the spec.

[starksm64]

We will certainly address the details of what the claims are named and how they need to map to the standard container APIs in the tck of the jwt-auth repository.

[arjantijms]

Hi Rudy, JACC is as of now not required. Only Servlet would be required, and if the fear (still for lack of better term) against JASPIC is so great, then for the MicroProfile that could always be an implementation detail. Of course, the exact behaviour of authentication could then be wildly different between servers, but that's what it is then. An other option would be to essentially redo JASPIC, but just not call it JASPIC and have some different interfaces. Then it would seem more modern and may take away some of the fear, even though in the end it would essentially do the same thing. Servlet containers (and the unspecified "http engine on which JAX-RS implicitly depends and abstracts from) could then implement this as a third SPI. I'm thinking here about specifying things like whether an authentication module should be called for every request (protected or not-protected) and whether it should automatically create a session or, and what happens when you want to authenticate programmatically in the middle of a request and such things. That is basically what JASPIC now specifies really well, and what should have to be redone then. Otherwise you get into the situation that say WildFly only calls the authentication module for protected resources, and Liberty calls it for both protected and not protected ones. Yet another option would be to implicitly require JASPIC, but not expose it to application code. Some modularity magic could do the trick there. Also another option is to have the Servlet Container Profile of JASPIC includes into Servlet. Then the perhaps troublesome JASPIC name would also disappear and it would just all be Servlet. In the end though I'm not sure if just fear of the name JASPIC should justify such work. Maybe it's better to look into why people think they have to fear JASPIC and what we can do to take this fear away? Remember that all Servlet containers already have their native authentication SPI as well, which is implicitly included, and with the exception of perhaps WildFly is often much older than JASPIC. Kind regards, Arjan Tijms

…

On Tue, May 30, 2017 at 3:09 PM, Rudy De Busscher ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In proposals/0005-jwt-rbac.md <#18 (comment)> : > + } +``` +The **realm_access** claim can be used to define which roles were granted to a subject at the realm or security domain level. On the other hand, the **resource_access** claim allows to define a different set of roles which are associated with a specific resource server or service. + +It is recommend that signature portion of the token should be signed using the RS256 algorithm using the RSA private key associated with the realm so that clients and services may verify the signature using the RSA realm public key. This corresponds to a JWT header with the following **alg** and **typ** claims: +``` +{ + "alg": "RS256", + "typ": "JWT", + "kid": "..." +} +``` + +## Impact on existing code (if applicable) + +Existing services that desire to implement JWT RBAC must configure the container to support integration with an authorization implementation that is capable of parsing the JWT bearer token to validate the token and populate a security context with the caller and granted roles for use in ```getCallerPrincipal()/getUserPrincipal(), isCallerInRole(String)/isUserInRole(String)``` type of container methods. Sorry to jump into the discussion at such a late point. I see in the proposal a very good description of the JWT and "protocol" which will be used to communicate the authentication/authorization information to some endpoint. But will be there a description how the info (username, roles, ...) will be transferred to the "container"? When using @Inject private Principal; there will be access to the username, but not to the "roles". There was a mentioning of using Soteria/JSR-375 which is mainly a layer on top of JASPIC (and JACC). Going that way, we specify that every MicroProfile compliant server will need those specs. Which is not recommended in my opinion. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC5XTpZXL9u-iK1bRKH_BdX5mDRCimczks5r_BT6gaJpZM4MZ2aE> .

[rdebusscher]

Hi Arjan, Since I started working on Soteria, I no longer fear JASPIC (also thanks to you :) ) but in the case, we include it in MicroProfile, we should consider - The not so good name of JASPIC (old style, too complex to configure [factory, factory of a factory, factory of a factory of a factory, ...], ...) - Not standardized way (as you mention yourself, there are differences in interpretation and implementation) it is implemented in the current servers nowadays - Is it Micro, Lightweight, ...? So when it is an implementation detail (how the token is transferred to the "container"), fine for me. The main question is then, how are the Roles used? - Should we define something like @RequiresUser (Shiro alike), @RolesAllowed (EJB), AccessDecissionVoter (DeltaSpike), ??? - Which class can we inject to have the roles of the authenticated caller programmatically (like the Principal) ?? - @RequestScoped or some new scope? best regards Rudy

…

On 30 May 2017 at 15:29, Arjan Tijms ***@***.***> wrote: Hi Rudy, JACC is as of now not required. Only Servlet would be required, and if the fear (still for lack of better term) against JASPIC is so great, then for the MicroProfile that could always be an implementation detail. Of course, the exact behaviour of authentication could then be wildly different between servers, but that's what it is then. An other option would be to essentially redo JASPIC, but just not call it JASPIC and have some different interfaces. Then it would seem more modern and may take away some of the fear, even though in the end it would essentially do the same thing. Servlet containers (and the unspecified "http engine on which JAX-RS implicitly depends and abstracts from) could then implement this as a third SPI. I'm thinking here about specifying things like whether an authentication module should be called for every request (protected or not-protected) and whether it should automatically create a session or, and what happens when you want to authenticate programmatically in the middle of a request and such things. That is basically what JASPIC now specifies really well, and what should have to be redone then. Otherwise you get into the situation that say WildFly only calls the authentication module for protected resources, and Liberty calls it for both protected and not protected ones. Yet another option would be to implicitly require JASPIC, but not expose it to application code. Some modularity magic could do the trick there. Also another option is to have the Servlet Container Profile of JASPIC includes into Servlet. Then the perhaps troublesome JASPIC name would also disappear and it would just all be Servlet. In the end though I'm not sure if just fear of the name JASPIC should justify such work. Maybe it's better to look into why people think they have to fear JASPIC and what we can do to take this fear away? Remember that all Servlet containers already have their native authentication SPI as well, which is implicitly included, and with the exception of perhaps WildFly is often much older than JASPIC. Kind regards, Arjan Tijms On Tue, May 30, 2017 at 3:09 PM, Rudy De Busscher < ***@***.***> wrote: > ***@***.**** commented on this pull request. > ------------------------------ > > In proposals/0005-jwt-rbac.md > <https://github.com/eclipse/microprofile-evolution- process/pull/18#discussion_r119093611> > : > > > + } > +``` > +The **realm_access** claim can be used to define which roles were granted to a subject at the realm or security domain level. On the other hand, the **resource_access** claim allows to define a different set of roles which are associated with a specific resource server or service. > + > +It is recommend that signature portion of the token should be signed using the RS256 algorithm using the RSA private key associated with the realm so that clients and services may verify the signature using the RSA realm public key. This corresponds to a JWT header with the following **alg** and **typ** claims: > +``` > +{ > + "alg": "RS256", > + "typ": "JWT", > + "kid": "..." > +} > +``` > + > +## Impact on existing code (if applicable) > + > +Existing services that desire to implement JWT RBAC must configure the container to support integration with an authorization implementation that is capable of parsing the JWT bearer token to validate the token and populate a security context with the caller and granted roles for use in ```getCallerPrincipal()/getUserPrincipal(), isCallerInRole(String)/isUserInRole(String)``` type of container methods. > > Sorry to jump into the discussion at such a late point. > > I see in the proposal a very good description of the JWT and "protocol" > which will be used to communicate the authentication/authorization > information to some endpoint. > > But will be there a description how the info (username, roles, ...) will > be transferred to the "container"? > When using > @Inject private Principal; > there will be access to the username, but not to the "roles". > > There was a mentioning of using Soteria/JSR-375 which is mainly a layer on > top of JASPIC (and JACC). Going that way, we specify that every > MicroProfile compliant server will need those specs. Which is not > recommended in my opinion. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/eclipse/microprofile-evolution- process/pull/18#discussion_r119093611>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AC5XTpZXL9u-iK1bRKH_ BdX5mDRCimczks5r_BT6gaJpZM4MZ2aE> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK96b7es_qI6esBh9CCiPx1XGZuLwJSks5r_BmhgaJpZM4MZ2aE> .

[arjantijms]

Hi, On Tue, May 30, 2017 at 4:26 PM, Rudy De Busscher <notifications@github.com> wrote:

Hi Arjan, Since I started working on Soteria, I no longer fear JASPIC (also thanks to you :) )

I know ;) But many people indeed still fear it, sometimes just because they don't know what it is. We should perhaps try to find why they fear it. Is it the API, or do they think it consumes much memory or much CPU, or...?

but in the case, we include it in MicroProfile, we should consider - The not so good name of JASPIC (old style, too complex to configure [factory, factory of a factory, factory of a factory of a factory, ...], ...)

The factory - factory - factory (or the "100 lines of horrible code" as Mark Struberg calls it), is insane. But the thing is, even in JASPIC's most arcane variant, you actually would not have needed to even see those. The implementation normally provides those (and they do), so that the user only had to provide the SAM. So the entirety of JASPIC for the user boils down to understanding 1 type; ServerAuthModule, and that's a little arcane (some would say low-level) but not over the top. Now the biggest single crazy mistake in JASPIC is not providing a "registerSam" method on the AuthConfigFactory. So now "everyone" complains about the factory-factory-factory, but in reality you never need to understand those and never have to work with them for a specific use case. You copy that implementation code once and forget about it.

- Not standardized way (as you mention yourself, there are differences in interpretation and implementation) it is implemented in the current servers nowadays

The spec is relatively fine, but the TCK is lacking. Current day implementations of JASPIC are near perfect. This was a concern when JASPIC just came out, but not any longer.

- Is it Micro, Lightweight, ...?

The SAM itself is so Micro and LightWeight that it becomes difficult again because of that :O I.e. it contains no conveniences, syntactic sugar, or utility methods whatsoever. It's just a very bare filter type of SPI. But since MicroProfile is not bounded to EE specifically, I wonder if it may be possible to depend on a sub-set of a JASPIC profile. So basically the Servlet Container Profile, without the factory-factory-factory.

So when it is an implementation detail (how the token is transferred to the "container"), fine for me. The main question is then, how are the Roles used?

There's multiple options. First of all security constraints in web.xml. Everyone knows these already.

- Should we define something like @RequiresUser (Shiro alike), @RolesAllowed (EJB), AccessDecissionVoter (DeltaSpike), ???

@RolesAllowed indeed, and extend these to JAX-RS methods as well (this was in scope for JAX RS 2.1) and proprietary implementations already support that, either out of the box or after some configuration. Unfortunately we didn't get to security interceptors for JSR 375, but it would be hesitant to specify something in another spec what JSR 375 is also about to specific. Hopefully we can file a 1.1 JSR for JSR 375 soon and address those interceptors there. For now I'd say @RolesAllowed is -the- vehicle to test for roles, combined with SecurityContext.isCallerInRole and SecurityContext.getAllCallerRoles

- Which class can we inject to have the roles of the authenticated caller programmatically (like the Principal) ??

@Inject SecurityContect context; And then context.getAllCallerRoles() :P At least, if we can convince Will in JSR 375 to put that method back.

…

- @RequestScoped or some new scope? best regards Rudy On 30 May 2017 at 15:29, Arjan Tijms ***@***.***> wrote: > Hi Rudy, > > JACC is as of now not required. > > Only Servlet would be required, and if the fear (still for lack of better > term) against JASPIC is so great, then for the MicroProfile that could > always be an implementation detail. > > Of course, the exact behaviour of authentication could then be wildly > different between servers, but that's what it is then. > > An other option would be to essentially redo JASPIC, but just not call it > JASPIC and have some different interfaces. Then it would seem more modern > and may take away some of the fear, even though in the end it would > essentially do the same thing. Servlet containers (and the unspecified > "http engine on which JAX-RS implicitly depends and abstracts from) could > then implement this as a third SPI. I'm thinking here about specifying > things like whether an authentication module should be called for every > request (protected or not-protected) and whether it should automatically > create a session or, and what happens when you want to authenticate > programmatically in the middle of a request and such things. > > That is basically what JASPIC now specifies really well, and what should > have to be redone then. Otherwise you get into the situation that say > WildFly only calls the authentication module for protected resources, and > Liberty calls it for both protected and not protected ones. > > Yet another option would be to implicitly require JASPIC, but not expose it > to application code. Some modularity magic could do the trick there. > > Also another option is to have the Servlet Container Profile of JASPIC > includes into Servlet. Then the perhaps troublesome JASPIC name would also > disappear and it would just all be Servlet. > > In the end though I'm not sure if just fear of the name JASPIC should > justify such work. Maybe it's better to look into why people think they > have to fear JASPIC and what we can do to take this fear away? > > Remember that all Servlet containers already have their native > authentication SPI as well, which is implicitly included, and with the > exception of perhaps WildFly is often much older than JASPIC. > > Kind regards, > Arjan Tijms > > > > > > > On Tue, May 30, 2017 at 3:09 PM, Rudy De Busscher < > ***@***.***> > wrote: > > > ***@***.**** commented on this pull request. > > ------------------------------ > > > > In proposals/0005-jwt-rbac.md > > <https://github.com/eclipse/microprofile-evolution- > process/pull/18#discussion_r119093611> > > : > > > > > + } > > +``` > > +The **realm_access** claim can be used to define which roles were > granted to a subject at the realm or security domain level. On the other > hand, the **resource_access** claim allows to define a different set of > roles which are associated with a specific resource server or service. > > + > > +It is recommend that signature portion of the token should be signed > using the RS256 algorithm using the RSA private key associated with the > realm so that clients and services may verify the signature using the RSA > realm public key. This corresponds to a JWT header with the following > **alg** and **typ** claims: > > +``` > > +{ > > + "alg": "RS256", > > + "typ": "JWT", > > + "kid": "..." > > +} > > +``` > > + > > +## Impact on existing code (if applicable) > > + > > +Existing services that desire to implement JWT RBAC must configure the > container to support integration with an authorization implementation that > is capable of parsing the JWT bearer token to validate the token and > populate a security context with the caller and granted roles for use in > ```getCallerPrincipal()/getUserPrincipal(), isCallerInRole(String)/ isUserInRole(String)``` > type of container methods. > > > > Sorry to jump into the discussion at such a late point. > > > > I see in the proposal a very good description of the JWT and "protocol" > > which will be used to communicate the authentication/authorization > > information to some endpoint. > > > > But will be there a description how the info (username, roles, ...) will > > be transferred to the "container"? > > When using > > @Inject private Principal; > > there will be access to the username, but not to the "roles". > > > > There was a mentioning of using Soteria/JSR-375 which is mainly a layer > on > > top of JASPIC (and JACC). Going that way, we specify that every > > MicroProfile compliant server will need those specs. Which is not > > recommended in my opinion. > > > > — > > You are receiving this because you were mentioned. > > Reply to this email directly, view it on GitHub > > <https://github.com/eclipse/microprofile-evolution- > process/pull/18#discussion_r119093611>, > > or mute the thread > > <https://github.com/notifications/unsubscribe- auth/AC5XTpZXL9u-iK1bRKH_ > BdX5mDRCimczks5r_BT6gaJpZM4MZ2aE> > > > . > > > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <https://github.com/eclipse/microprofile-evolution- process/pull/18#issuecomment-304878069>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ABK96b7es_ qI6esBh9CCiPx1XGZuLwJSks5r_BmhgaJpZM4MZ2aE> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#18 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC5XTrTNZS98pGzEuPeKhLPMksrNouXYks5r_CcagaJpZM4MZ2aE> .

[johnament]

@rdebusscher @arjantijms while these are great comments, we're getting into how the spec is going to work. The goal of the proposal is to say " we want to do something with JWT " not "this is how we're going to use JWT"

[mikecroft]

Merged after successful vote:
https://groups.google.com/forum/#!topic/microprofile/z0gen1KcThc