[VOTE] MP-0005 JWT RBAC

[sst...@redhat.com]

I think we are at the point were we can vote on moving the JWT RBAC(https://github.com/eclipse/microprofile-evolution-process/pull/18) proposal forward .

A repository for the code has been created here:

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

And the initial content has been created and is available in this pull request:

https://github.com/eclipse/microprofile-jwt-auth/pull/2

This include the proposal in asciidoc format with discussion points from the proposal comments added.

You can pull down the content from my fork:

https://github.com/starksm64/microprofile-jwt-auth

[John D. Ament]

+1

[Mark Little]

+1

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4ceed7f2-21a8-4404-8d84-4c4e1abba1de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chunlong Liang]

+1

[Kevin Sutter]

+1 (with a minor comment to change JEE to Java EE)

[Kevin Sutter]

Scott,
I just noticed that the proposal (https://github.com/eclipse/microprofile-evolution-process/pull/18) has been merged yet...  It looks like a comment from John Ament needs to be addressed (removing the reference to the specific MicroProfile 1.1 release).  We should get this cleaned up and merged before (or at same time) as these other changes get approved and moved forward.  Thanks.

Kevin

[sst...@redhat.com]

I have removed the 1.1 reference and changed JEE to Java EE.

[Mike Croft]

+1

[Martijn Verburg]

+1

Cheers,
Martijn

On 1 June 2017 at 09:36, Mike Croft <backtoth...@gmail.com> wrote:

+1

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.

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

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b56ab7f2-6b87-40cd-bdca-e3978ab15c88%40googlegroups.com.

[Mike Croft]

Given that:

• We discussed and agreed previously on using Apache voting guidelines
• After 1 week, those guidelines are satisfied (more than 3 +1s and no -1s)

I'm going to merge this PR.

[sst...@redhat.com]

Can you merge the outstanding microprofile-jwt-auth PR as well so we can start working there?

https://github.com/eclipse/microprofile-jwt-auth/pull/2

[Mike Croft]

Done

--
You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/z0gen1KcThc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/f5e97b3b-9f9d-4489-9df4-e22769a76ef1%40googlegroups.com.

[Kevin Sutter]

Hi Scott,
Now that the proposal has been accepted and the repo has been created and initialized, what are the JWT plans going forward?  I'm starting to consider the content for MP 1.2 and wondering whether the JWT RBAC 1.0 will be ready.  The discussions have been kind of quiet, so just pinging to see how's it going.

Thanks, Kevin

On Friday, June 9, 2017 at 10:37:48 AM UTC-5, Mike Croft wrote:

Done

On Fri, 9 Jun 2017 16:35 , <sst...@redhat.com> wrote:

Can you merge the outstanding microprofile-jwt-auth PR as well so we can start working there?

https://github.com/eclipse/microprofile-jwt-auth/pull/2

On Thursday, June 8, 2017 at 5:43:25 AM UTC-7, Mike Croft wrote:

Given that:

• We discussed and agreed previously on using Apache voting guidelines
• After 1 week, those guidelines are satisfied (more than 3 +1s and no -1s)

I'm going to merge this PR.

--
You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/z0gen1KcThc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.

[John D. Ament]

I'm also a bit curious to know what the scope of this spec is intended to be.  For instance, do we have to say anything more than a MP implementation will support consuming OIDC standard JWTs in a request using both Authorization Bearer header or access_token query params?  I don't see anything that would necessarily be added from an API standpoint (but granted, we don't require servlet in our specs, do we also want to say that the SecurityContext from JAX-RS will be overridden?).

John

[sst...@redhat.com]

I'm preparing a new pull request for the microprofile-jwt-auth repo that adds the initial proof of concept default implementations of a IdentifyStore and ServerAuthModule to illustrate the requirements for a JWT RBAC provider. I'm hopeful we can work to agree on exactly what the encoding format of the token is, and then have default/base implementation that support that relatively quickly.

On Friday, June 30, 2017 at 8:01:14 AM UTC-7, Kevin Sutter wrote:

Hi Scott,
Now that the proposal has been accepted and the repo has been created and initialized, what are the JWT plans going forward?  I'm starting to consider the content for MP 1.2 and wondering whether the JWT RBAC 1.0 will be ready.  The discussions have been kind of quiet, so just pinging to see how's it going.

Thanks, Kevin

On Friday, June 9, 2017 at 10:37:48 AM UTC-5, Mike Croft wrote:

Done

On Fri, 9 Jun 2017 16:35 , <sst...@redhat.com> wrote:

Can you merge the outstanding microprofile-jwt-auth PR as well so we can start working there?

https://github.com/eclipse/microprofile-jwt-auth/pull/2

On Thursday, June 8, 2017 at 5:43:25 AM UTC-7, Mike Croft wrote:

Given that:

• We discussed and agreed previously on using Apache voting guidelines
• After 1 week, those guidelines are satisfied (more than 3 +1s and no -1s)

I'm going to merge this PR.

--
You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/z0gen1KcThc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

[sst...@redhat.com]

It will be an extension of the OIDC JWT standard set of claims that support role based authorization. I am also proposing a standard JWTCallerPrincipal extension of javax.security.enterprise.CallerPrincipal that provides access to the token and its claims set.

On Saturday, July 1, 2017 at 5:41:40 AM UTC-7, John D. Ament wrote:

I'm also a bit curious to know what the scope of this spec is intended to be.  For instance, do we have to say anything more than a MP implementation will support consuming OIDC standard JWTs in a request using both Authorization Bearer header or access_token query params?  I don't see anything that would necessarily be added from an API standpoint (but granted, we don't require servlet in our specs, do we also want to say that the SecurityContext from JAX-RS will be overridden?).

John

On Friday, June 30, 2017 at 11:01:14 AM UTC-4, Kevin Sutter wrote:

Hi Scott,
Now that the proposal has been accepted and the repo has been created and initialized, what are the JWT plans going forward?  I'm starting to consider the content for MP 1.2 and wondering whether the JWT RBAC 1.0 will be ready.  The discussions have been kind of quiet, so just pinging to see how's it going.

Thanks, Kevin

On Friday, June 9, 2017 at 10:37:48 AM UTC-5, Mike Croft wrote:

Done

On Fri, 9 Jun 2017 16:35 , <sst...@redhat.com> wrote:

Can you merge the outstanding microprofile-jwt-auth PR as well so we can start working there?

https://github.com/eclipse/microprofile-jwt-auth/pull/2

On Thursday, June 8, 2017 at 5:43:25 AM UTC-7, Mike Croft wrote:

Given that:

• We discussed and agreed previously on using Apache voting guidelines
• After 1 week, those guidelines are satisfied (more than 3 +1s and no -1s)

I'm going to merge this PR.

--
You received this message because you are subscribed to a topic in the Google Groups "MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/z0gen1KcThc/unsubscribe.

To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

[Chunlong Liang]

We should have more discussion on the standard set of claims, in particular for OIDC claim "nonce" and "jti". If we want to recommend the "nonce", we need state how the "nonce" is supposed to be verified, as the verification is different from Openid Connect client. The openid connect states
 "If a nonce value was sent in the Authentication Request, a nonce Claim MUST be present and its value checked to verify that it is the same value as the one that was sent in the Authentication Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is Client specific. "  Here we could not verify "nonce" in the way defined in Openid Connect spec.

On the other hand, in JWT spec, the "jti" is defined as
"

 The "jti" (JWT ID) claim provides a unique identifier for the JWT.
   The identifier value MUST be assigned in a manner that ensures that
   there is a negligible probability that the same value will be
   accidentally assigned to a different data object; if the application
   uses multiple issuers, collisions MUST be prevented among values
   produced by different issuers as well.  The "jti" claim can be used
   to prevent the JWT from being replayed.  The "jti" value is a case-
   sensitive string.  Use of this claim is OPTIONAL.

"
For this spec, I would say that we should just recommend to use "jti" for detecting replay attack, and we recommend not to include this optional "nonce" claim in JWT.

[sst...@redhat.com]

Ok, good as that is the direction I am taking in the initial proposal I have about to go into the microprofile-jwt-auth change set; using jti, not requiring nonce.

[Chunlong Liang]

To support API JWTCallerPrincipal, I guess we would need map JWTCallerPrincipal to one JWT claim. The "sub" claim could be used as JWTCallerPrincipal if "sub" is public, and not pairwise. However, if "sub" is pairwise, do we want to recommend one claim as JWTCallerPrincipal? or want to make implementation specific?
The initial proposal has "preferred_username" claim, which is not unique, and could not be used as JWTCallerPrincipal. Should we introduce a new claim? or modify "preferred_username" to be unique that can be used as JWTCallerPrincipal?

On Saturday, July 1, 2017 at 12:29:50 PM UTC-5, sst...@redhat.com wrote:

[John D. Ament]

Granted, I'm new to JWT, but the useful bits seem to be:

- preferred_username

- given name/family name

- email

- realm_access/roles.  There also seems to be another one specific to the application subject.

sub/nonce etc seem useful for validation and verification, not useful for the end user.  It would be good to have a single principal that was user centric, rather than one we need to worry about.

Also, since this is the vote thread does it make sense to have a separate thread to start talking about details?

John

[sst...@redhat.com]

The sub claim is supposed to be tied to either the resource owner or client_id depending on the token usage according to:

https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-12

so I think we need to leverage a custom claim like preferred_username and require uniqueness.

[sst...@redhat.com]

I just ran across this unified view of the various claims from JWT intersecting specs:

https://www.iana.org/assignments/jwt/jwt.xhtml

so we can standardize what is required from that list and introduce the role/group claims to deal with the EE role based authorization information.

I'm seeing a bit of a disconnect with respect to how we were originally thinking about how the role information is encoded in the token, and I see that this is something Chunlong was asking about. What we were thinking is that the JWT would represent a complete authentication token as indicated by it being by a realm issuer given by the "iss" claim, and signed by the realm issuer public key. Similarly, it would contain the complete role based authorization information by encoding the application domain roles as mapped by the realm into the application domain space to avoid the need to perform container level group to role mapping. In working on the IdentityStore implementation, I see this cannot really be done as the api is just returning a Set<String> of group names.

I know it is common to have a one to one mapping between roles and group names, so I'm wondering if there is a way to support this common mapping. I believe that Glassfish and Liberty need to provide a container specific configuration to enable the one to one role to group name association. Is there a way that could be triggered without the container configuration? If not, we'll have to rethink how the role/group information is encoded.

[Alasdair Nottingham]

Hi,

Liberty does support a 1-1 mapping of role to group name if no other role mapping is provided. However I think insisting that there is a 1-1 for JWT would be a mistake. I’ve always like the Java EE role based access control model and I think equating it to a group based model is a serious limitation in useful function.

Alasdair

--

You received this message because you are subscribed to the Google Groups "MicroProfile" group.

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

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/2ca3a2e1-60f5-487b-95f7-cc64962b3af2%40googlegroups.com.

[sst...@redhat.com]

We're not insisting, just wondering if it can be universally supported. The reasoning is that the user to role mapping can have already happened at the IDP issuing the JWT. The benefit is that not all micro profile container runtimes have this notion of group to role mapping, and it can simplify EE deployments as well if the default is what Liberty and I know Wildfly//Swarm do.

So the question is how to convey that the token has been granted roles vs groups. Is it just a groups claim with an array of names? Is it a role to group mapping like is done via container specific descriptors? 

[Kevin Sutter]

+1 John on your idea to start a new thread of discussion...  This [VOTE] was passed and the proposal accepted.  It's time to move on to other threads or Issue discussions.

Thanks, Kevin

[sst...@redhat.com]

Sorry, I was not paying attention to the thread title, just responding.

I'll start a new I get the current changes in a pull request today.

[Chunlong Liang]

Let me try to summarize the requirement of JWT token. The JWT need meet those goals:
1. An authentication token, and 
2. An authorization token that contains J2EE role based authorization directly or indirectly granted with group
3. Can be mapped to IdentityStore in JSR375,
4. Can support standard claims in https://www.iana.org/assignments/jwt/jwt.xhtml

To meet those requirements, we can introduce 3 new claims to define the JWT:

"unique_username" or "upn": Human readable claim that uniquely identify subject or user principal of token.
"groups": The subject's group membership.
"roles": The application roles that the subject has been granted directly and indirectly through groups claim.

The "unique_username" or "upn" is user principal, and is the caller principal in IdentityStore. If this claim is ommitted, the "sub" itself is used as caller principal.

The "groups" contains group membership of caller principal in IdentityStore.
the "roles" contains granted application roles through "groups" or "unique_username" claims.

A JWT can contains both "roles" and "groups", or just "groups" or "roles". If JWT only contains "roles", it is the returned values of getGroupsByCallerPrincipal(CallerPrincipal).

The recommended minimum JWT would be
{
     "typ": "JWT",
    "alg": "RS256",
    "kid": "abc-1234567890"
}
{
       "iss": "https://server.example.com",
       "aud": "s6BhdRkqt3",
       "exp": 1311281970,
       "iat": 1311280970,
       "sub": "24400320",
        "unique_username <or "upn">": "jd...@server.example.com",
        "groups": ["red-group", "green-group", "admin-group"],
       "roles": ["auditor", "administrator"]
}

The JWT can contains all other optional and standard claims:

{
       "iss": "https://server.example.com",
       "aud": "s6BhdRkqt3",
       "exp": 1311281970,
       "iat": 1311280970,
       "sub": "24400320",

        "unique_username <or "upn">": "jd...@server.example.com",
        "groups: ["red-group", "green-group", "admin-group"],
    "roles": ["auditor", "administrator"],

       "jti": "a-123",
       "auth_time": 1311280969,
        "preferred_username": "jdoe",
        "acr": "phr",
        "nbf":  1311288970
        ....... <and all other claims defined by JWT spec and OIDC spec>

[Emily Jiang]

I suggest you guys to get together with a regular hangout or bluejen meeting, as I found the meetup worked out very well. Most spec have regular meetup now. It is much easier to explain the technical details on the call.

Emily