toggle quoted messageShow quoted text
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).
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.
On Jul 11, 2017, at 10:59 AM, Will Hopkins <firstname.lastname@example.org> 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.
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.
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803