Topics

Java EE Security.next and JWT (JSON Web Tokens)


Arjan Tijms
 

Hi,

On Wednesday, July 12, 2017, Werner Keil <werner.keil@...> wrote:
com.google.api.client.auth.oauth2.TokenResponse

For anything that could become part of an official JSR deliverable, that doesn't sound so good;-/

Indeed, which was the most important reason to not include it as-is ;)
 
Agorava also used Scribe in the initial draft phase, but it was changed, so other than CDI compliant DeltaSpike the only thing that is not fully based on Java EE would be Jackson right now.
PicketLink, but IMO all relevant aspects of PicketLink are now found in JSR 375/Soteria, so porting https://github.com/agorava/agorava-core/tree/develop/agorava-picketlink to use Soteria should be extremely easy. The Oauth part is already there independent of Google or other libraries.

Sounds cool ;)
 

Kind Regards,
Werner


Werner Keil
 

com.google.api.client.auth.oauth2.TokenResponse

For anything that could become part of an official JSR deliverable, that doesn't sound so good;-/
Agorava also used Scribe in the initial draft phase, but it was changed, so other than CDI compliant DeltaSpike the only thing that is not fully based on Java EE would be Jackson right now.
PicketLink, but IMO all relevant aspects of PicketLink are now found in JSR 375/Soteria, so porting https://github.com/agorava/agorava-core/tree/develop/agorava-picketlink to use Soteria should be extremely easy. The Oauth part is already there independent of Google or other libraries.

Kind Regards,
Werner


Arjan Tijms
 

Hi,

I would also assume that only the consuming part is needed as an authentication mechanism.

The typical use is to authenticate with Facebook, Google and Twitter. Another OAuth2 client example that's already based on Soteria: https://github.com/omnifaces/soteria-google-oauth-client

Kind regards,
Arjan Tijms


On Wed, Jul 12, 2017 at 6:43 PM, Werner Keil <werner.keil@...> wrote:
For the consuming part have a look at http://www.agorava.org/ (created by CDI Spec Lead Antoine and myself as a result of a "Social" JSR being turned down by the EC and to succeed Seam Social)
Except Mockito there are very few parts that are not based on standards or can be under Java EE 8 (with a little work Jackson Binding can be replaced by JSON-B 1.0)

CDI (1.1) and JAX-RS 2.0 are already used.

Werner



Werner Keil
 

For the consuming part have a look at http://www.agorava.org/ (created by CDI Spec Lead Antoine and myself as a result of a "Social" JSR being turned down by the EC and to succeed Seam Social)
Except Mockito there are very few parts that are not based on standards or can be under Java EE 8 (with a little work Jackson Binding can be replaced by JSON-B 1.0)

CDI (1.1) and JAX-RS 2.0 are already used.

Werner


Will Hopkins
 

In terms of OAuth2, I don't think it's a case of standing up an authorization server, it's more a case of being able to consume OAuth2 access tokens, as distinct from OpenID Connect identity tokens. Support for access tokens, especially (or perhaps exclusively) for JAX-RS applications, would presumably be very popular. Access tokens bring with them a certain amount of complexity, though, as they involve two distinct "subjects" (application client, resource owner) and an authorization model involving claims (scopes) asserted by the authorization server, that the resource server must honor. Since claims are app-specific, there's also an implied requirement for out-of-band configuration exchange with the authorization server, which would be useful to automate in some way (maybe something like SAML2 metadata?), and resource servers/apps probably need some type of configuration to describe the format/content of tokens they're willing/able to consume.

On 07/11/2017 05:43 PM, David Blevins wrote:
A few thoughts:

  - Crypto: It’s only the extended policy files (JCE) that are restricted.  The JVM has rsa-sha256 built-in, so we’re good.  JWTs support anything, but we’d have an opinionated perspective and say “the server must support verifying an RSA-SHA256 signed JWT”.  Anything else could be vendor specific (aka open to being a requirement later).

  - OAuth2: I’m not sure it makes sense for us to “include” OAuth 2.0.  Specifically, the app server issuing OAuth 2.0 access tokens is not a pattern I see anyone doing or on the horizon.  What I see is people propping up OAuth 2.0 gateways in front of their LDAP server.  These OAuth 2.0 servers are issuing JWT tokens with a “snapshot” of LDAP data, they are signed by the OAuth 2.0 Gateway.  More and more the server is not the one performing the token grant with the Gateway and obtaining the JWT access token.  It’s often being done by the browser via javascript or the mobile device, after which point the token is passed with all calls.  The app server needs only to check the signature to verify the JWT when a request comes in with an "Authentication: Bearer <the jwt access token>” header.  This can be done with a RSA public key provided by the OAuth 2.0 Gateway.

The short version, IMO, our job is really just to require the server can verify the token.  Ideally with an additional requirement that the server support being able to map fields from the json map (the token’s payload) to answer “isCallerInRole” and “getCallerPrincipal” calls.

I think if we got that far, we’d be good for several years.



-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


David Blevins
 

A few thoughts:

- Crypto: It’s only the extended policy files (JCE) that are restricted. The JVM has rsa-sha256 built-in, so we’re good. JWTs support anything, but we’d have an opinionated perspective and say “the server must support verifying an RSA-SHA256 signed JWT”. Anything else could be vendor specific (aka open to being a requirement later).

- OAuth2: I’m not sure it makes sense for us to “include” OAuth 2.0. Specifically, the app server issuing OAuth 2.0 access tokens is not a pattern I see anyone doing or on the horizon. What I see is people propping up OAuth 2.0 gateways in front of their LDAP server. These OAuth 2.0 servers are issuing JWT tokens with a “snapshot” of LDAP data, they are signed by the OAuth 2.0 Gateway. More and more the server is not the one performing the token grant with the Gateway and obtaining the JWT access token. It’s often being done by the browser via javascript or the mobile device, after which point the token is passed with all calls. The app server needs only to check the signature to verify the JWT when a request comes in with an "Authentication: Bearer <the jwt access token>” header. This can be done with a RSA public key provided by the OAuth 2.0 Gateway.

The short version, IMO, our job is really just to require the server can verify the token. Ideally with an additional requirement that the server support being able to map fields from the json map (the token’s payload) to answer “isCallerInRole” and “getCallerPrincipal” calls.

I think if we got that far, we’d be good for several years.


--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
310-633-3852

On Jul 11, 2017, at 10:59 AM, Will Hopkins <will.hopkins@...> wrote:

It's indeed to late to add JWT support, or OpenID Connect, or OAuth2. ;)

Regarding encryption, wouldn't it be feasible to depend on crypto libraries without actually delivering them? I.e., say, "This API and RI works when the Xyz crypto lib is present, compatible versions are X, available from Y. Please obtain these libraries before attempting to use this JSR"? It would probably be fairly straightforward to keep crypto out of the API itself.

Will

On 07/11/2017 09:36 AM, Werner Keil wrote:
Actually JetBrains mentioned something like OpenID only, which they hopefully mean "OpenID Connect" since OpenID in its original form is long dead?;-)

I also abstained on JSR 310 both in the Public Draft (https://jcp.org/en/jsr/results?id=5603) and PFD. Due to issues, of which only the lack of ISO 8601 standard support was properly resolved.
While circular dependencies between TemporalAmount and RI element Duration were not resolved (on the ohter hand, the DateTimeFormatter returns only API level abstract Temporal types, not concrete final classes, so it is quite inconsistent and most importantly makes an independent implementation totally impossible)

After talking to Antoine at JavaOne he said, that server-side OAuth or OpenID Connect support would be very hard to accomplish in the brief timeframe EE 8 was given.
Arjan also highlighted, that OAuth, JWT, etc. depend on cryptography and the list of countries, that do not allow cryptography is rather long: https://en.wikipedia.org/wiki/Restrictions_on_the_import_of_cryptography#Status_by_country
(I gave a talk on JSR 321, Trusted Java at JavaOne Russia, but I did not do a live demo because using a TPM chip is illegal there;-)

Therefore adding crypto-libraries to Soteria/Glassfish by default could mean a lot of trouble for this JSR and products based on it.
Not sure, if they ever can be official parts of the RI in the future, or this will be entirely up to 3rd party vendors and open source projects.

That is among the reasons, why "security-samples" and similar extensions are probably as important as Soteria itself, if not more.

Kind Regards,
Werner
--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Will Hopkins
 

I have reached out to JetBrains to:
  • Provide them with an updated spec and javadoc that I think should address at least some of their concerns.
  • Explain the decision we made to not implement OpenID Connect or OAuth2 based on the limited time we had to complete the JSR, and our view that JSR-375 is nonetheless useful on its own merits, and as a foundation on which things like OpenID Connect can be implemented.
  • Request more information about their concerns.

They've said they'll respond with more information; hopefully we can address their concerns.

Will


On 07/10/2017 09:27 PM, David Blevins wrote:
Let me add I fully understand someone largely inactive popping up a the finish line and asking a massive scope creep question is frustrating.  I am understandably patient and really just curious on our thoughts.

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Will Hopkins
 

It's indeed to late to add JWT support, or OpenID Connect, or OAuth2.  ;)

Regarding encryption, wouldn't it be feasible to depend on crypto libraries without actually delivering them? I.e., say, "This API and RI works when the Xyz crypto lib is present, compatible versions are X, available from Y. Please obtain these libraries before attempting to use this JSR"? It would probably be fairly straightforward to keep crypto out of the API itself.

Will

On 07/11/2017 09:36 AM, Werner Keil wrote:
Actually JetBrains mentioned something like OpenID only, which they hopefully mean "OpenID Connect" since OpenID in its original form is long dead?;-)

I also abstained on JSR 310 both in the Public Draft (https://jcp.org/en/jsr/results?id=5603) and PFD. Due to issues, of which only the lack of ISO 8601 standard support was properly resolved.
While circular dependencies between TemporalAmount and RI element Duration were not resolved (on the ohter hand, the DateTimeFormatter returns only API level abstract Temporal types, not concrete final classes, so it is quite inconsistent and most importantly makes an independent implementation totally impossible) 

After talking to Antoine at JavaOne he said, that server-side OAuth or OpenID Connect support would be very hard to accomplish in the brief timeframe EE 8 was given. 
Arjan also highlighted, that OAuth, JWT, etc. depend on cryptography and the list of countries, that do not allow cryptography is rather long: https://en.wikipedia.org/wiki/Restrictions_on_the_import_of_cryptography#Status_by_country
(I gave a talk on JSR 321, Trusted Java at JavaOne Russia, but I did not do a live demo because using a TPM chip is illegal there;-)

Therefore adding crypto-libraries to Soteria/Glassfish by default could mean a lot of trouble for this JSR and products based on it. 
Not sure, if they ever can be official parts of the RI in the future, or this will be entirely up to 3rd party vendors and open source projects.

That is among the reasons, why "security-samples" and similar extensions are probably as important as Soteria itself, if not more.

Kind Regards,
Werner

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803


Werner Keil
 

Actually JetBrains mentioned something like OpenID only, which they hopefully mean "OpenID Connect" since OpenID in its original form is long dead?;-)

I also abstained on JSR 310 both in the Public Draft (https://jcp.org/en/jsr/results?id=5603) and PFD. Due to issues, of which only the lack of ISO 8601 standard support was properly resolved.
While circular dependencies between TemporalAmount and RI element Duration were not resolved (on the ohter hand, the DateTimeFormatter returns only API level abstract Temporal types, not concrete final classes, so it is quite inconsistent and most importantly makes an independent implementation totally impossible) 

After talking to Antoine at JavaOne he said, that server-side OAuth or OpenID Connect support would be very hard to accomplish in the brief timeframe EE 8 was given. 
Arjan also highlighted, that OAuth, JWT, etc. depend on cryptography and the list of countries, that do not allow cryptography is rather long: https://en.wikipedia.org/wiki/Restrictions_on_the_import_of_cryptography#Status_by_country
(I gave a talk on JSR 321, Trusted Java at JavaOne Russia, but I did not do a live demo because using a TPM chip is illegal there;-)

Therefore adding crypto-libraries to Soteria/Glassfish by default could mean a lot of trouble for this JSR and products based on it. 
Not sure, if they ever can be official parts of the RI in the future, or this will be entirely up to 3rd party vendors and open source projects.

That is among the reasons, why "security-samples" and similar extensions are probably as important as Soteria itself, if not more.

Kind Regards,
Werner


Arjan Tijms
 

>I understand time constraints, but I am also wondering what everyone’s thoughts are on JWT?

It's something that we really wanted to have in, along with OAuth2 support. OAuth2 was in scope from the beginning of the JSR really.

While I'm happy with all the great work that we did get in, it's also frustrating to see a number of things did not get in. Especially the security interceptors (CDI based @RolesAllowed replacement) and some modern authentication mechanisms that really go beyond what Servlet offers were high on at least my wish list.

A particular issue with both the JWT and OAuth2 prototypes / proof of concepts is that the most straightforward implementation depends on external libraries. If I understand correctly it's not trivial to get approval for the use of such libraries in the RI.

The current plan that we more or less had was to put these existing proof of concepts in a separate OSS library independent of the JCP and/or the RI, polish them there, and then try to get these standardised for the next revision of the Java EE Security API. That way most Java EE 8 users would have at least access to these mechanisms, with the additional hassle of having to include the OSS library in their apps.

Kind regards,
Arjan Tijms


reza_rahman <reza_rahman@...>
 

Certainly worth exploring if doing anything is possible. It does come up often enough these days at clients along with OAuth/OpenID Connect.

-------- Original message --------
From: David Blevins <dblevins@...>
Date: 7/10/17 9:10 PM (GMT-05:00)
To: javaee-security-spec@javaee.groups.io
Subject: [javaee-security-spec] Java EE Security.next and JWT (JSON Web Tokens)

There is one EC no vote due to lack of effectively JWT support.

I see Rudy has done some work very recently:


Scott has mentioned it recently as well, but I didn’t see a response.  You can add me into the JWT fan-club.

I understand time constraints, but I am also wondering what everyone’s thoughts are on JWT?

Would we need an actual API change or could we just say “you must support them”.  The TCK test would validate the server could:

 - Verify the JWT with a RSA public key (provided by the TCK)
 - Verify the server can map a JWT field to getCallerPrincipal
 - Verify the server can map a JWT field to isCallerInRole

We could punt on the specifics of how the server supports them or where the roles come from and work on those details next revision.  It seems like all servers will/do support them, so there is temptation to sneak it in even if the spec simply says “you must support them with this result” but doesn’t say how.

Rudy, I’m curious what you found in your work.

Will, any thoughts you have are great.

Understandably late and unactionable, but never hurts to ask :)  


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
310-633-3852


David Blevins
 

Let me add I fully understand someone largely inactive popping up a the finish line and asking a massive scope creep question is frustrating.  I am understandably patient and really just curious on our thoughts.


David Blevins
 

There is one EC no vote due to lack of effectively JWT support.

I see Rudy has done some work very recently:


Scott has mentioned it recently as well, but I didn’t see a response.  You can add me into the JWT fan-club.

I understand time constraints, but I am also wondering what everyone’s thoughts are on JWT?

Would we need an actual API change or could we just say “you must support them”.  The TCK test would validate the server could:

 - Verify the JWT with a RSA public key (provided by the TCK)
 - Verify the server can map a JWT field to getCallerPrincipal
 - Verify the server can map a JWT field to isCallerInRole

We could punt on the specifics of how the server supports them or where the roles come from and work on those details next revision.  It seems like all servers will/do support them, so there is temptation to sneak it in even if the spec simply says “you must support them with this result” but doesn’t say how.

Rudy, I’m curious what you found in your work.

Will, any thoughts you have are great.

Understandably late and unactionable, but never hurts to ask :)  


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com
310-633-3852