Date   

EC Vote and Proposed Final Draft submitted to JCP

Will Hopkins
 

A couple of announcements:
  • The Public Review Ballot passed, with 21 yes votes, 1 no vote, and 3 who didn't vote at all. The no vote was from JetBrains; I have reached out to them to ensure I understand their concerns, and to let them know that at least some of their concerns have already been addressed.
  • I've also released a PFD version of the spec and API, tagged 1.0-b06 in GitHub, and submitted it to the JCP. I would have liked more time for the EG to review, but I'm on a tight schedule. I'm aware of at least one error in the spec, so we may need to publish an update.
With that in mind, I would encourage everyone to read the updated spec/javadoc (attached/linked to this email) and comment, using the subject, "Proposed Final Draft Comments from <name>", but please limit comments to issues that represent significant errors, omissions, or limitations that affect the API's usability -- adding new functionality is not an option at this point! ;)
Thanks for everyone's help in resolving the last few technical issues. I plan to spend this week working on migrating the repos into the Java EE organization and cleaning up JIRAs.

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


Re: Moving to Java EE Github?

Werner Keil
 

Ok, let us know, if you need any help by those who have the necessary rights.


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

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


Re: Moving to Java EE Github?

Will Hopkins
 

I plan to move them asap, hopefully this week.

On 07/11/2017 08:40 AM, Werner Keil wrote:
Since Java EE 8 does not reference anything other than the JCP detail page of JSR 375 we should be OK to move e.g. after PFD went out.

The Spec with https://github.com/javaee-security-spec/security-spec (which has a history of several branches and release tags) and https://github.com/javaee/security-spec which has the entire JIRA history from java.net seems the most tricky part. Somehow we need to find a compromise between the codebase and issues. IMO both are equally important.

With enough Git experience and the right credentials, it should be possible to import all of https://github.com/javaee-security-spec/security-spec
into https://github.com/javaee/security-spec without losing any branch. The javaee repo only has "gh-pages" so "master" or any other branch and tags should be possible to import without having to delete either of the repos. And after it's succesful, the old one can be deleted. 

All other repositories probably best change ownerwhip if Will or somebody else at Oracle can transfer ownership between both organizations.

Regards,
Werner

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


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

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


Feature Freeze and EE 8

Will Hopkins
 

Hi Werner,

Linda and I sync'd up on that and I believe the two specs are consistent, although the EE 8 spec obviously doesn't go into as much detail and doesn't list every API.

Thanks,

Will

On 07/11/2017 08:31 AM, Werner Keil wrote:
Will,

I had a look at the PFD of Java EE 8 where Security is also referred, to, e.g. EE.3.3.4.2
  • isCallerInRole (SecurityContext)
  • getCallerPrincipal(SecurityContext) 
  • isCallerInRole (EJBContext) 
  • getCallerPrincipal (EJBContext) 
  • isUserInRole (HttpServletRequest) 
  • getUserPrincipal (HttpServletRequest)
So whatever changes we still come up with, once the EE 8 umbrella goes final, the API for 1.0 should also be considered feature frozen.
Luckily there's no direct reference to anything other than the JCP detail page, so moving within GitHub seems OK even after EE 8 went Final.

Werner

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


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

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


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

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


Re: Moving to Java EE Github?

Werner Keil
 

Since Java EE 8 does not reference anything other than the JCP detail page of JSR 375 we should be OK to move e.g. after PFD went out.

The Spec with https://github.com/javaee-security-spec/security-spec (which has a history of several branches and release tags) and https://github.com/javaee/security-spec which has the entire JIRA history from java.net seems the most tricky part. Somehow we need to find a compromise between the codebase and issues. IMO both are equally important.

With enough Git experience and the right credentials, it should be possible to import all of https://github.com/javaee-security-spec/security-spec
into https://github.com/javaee/security-spec without losing any branch. The javaee repo only has "gh-pages" so "master" or any other branch and tags should be possible to import without having to delete either of the repos. And after it's succesful, the old one can be deleted. 

All other repositories probably best change ownerwhip if Will or somebody else at Oracle can transfer ownership between both organizations.

Regards,
Werner


Re: Please Review security-api Pull Request #38 ASAP

Werner Keil
 

Will,

I had a look at the PFD of Java EE 8 where Security is also referred, to, e.g. EE.3.3.4.2
  • isCallerInRole (SecurityContext)
  • getCallerPrincipal(SecurityContext) 
  • isCallerInRole (EJBContext) 
  • getCallerPrincipal (EJBContext) 
  • isUserInRole (HttpServletRequest) 
  • getUserPrincipal (HttpServletRequest)
So whatever changes we still come up with, once the EE 8 umbrella goes final, the API for 1.0 should also be considered feature frozen.
Luckily there's no direct reference to anything other than the JCP detail page, so moving within GitHub seems OK even after EE 8 went Final.

Werner


Re: Default group to role mapping

Arjan Tijms
 

Hi,

On Mon, Jul 10, 2017 at 05:54 pm, David Blevins wrote:
I'm late to the party and it's already resolved, but just throwing in my +1 for having the mapping enabled by default.
Great, still very good to have that choice validated by such a long time Java EE expert as yourself :)


Incidentally, we also cast a yes vote on the Public Review Ballot :)

Thanks! :)

Kind regards,
Arjan Tijms


Re: Default group to role mapping

Arjan Tijms
 

It seems the ballot has already been accepted. Red Hat indeed didn't vote. See here: https://jcp.org/en/jsr/results?id=6011

On Tue, Jul 11, 2017 at 11:17 AM, Darran Lofthouse <darran.lofthouse@...> wrote:
I am probably missing this, where are we supposed to be casing this vote?

On Tue, 11 Jul 2017 at 01:54 <dblevins@...> wrote:
I'm late to the party and it's already resolved, but just throwing in my +1 for having the mapping enabled by default.

Incidentally, we also cast a yes vote on the Public Review Ballot :)



Re: Public Review Draft Comments Guillermo González de Agüero

Arjan Tijms
 

Hi,

It has indeed been removed, thanks for your confirmation that it was indeed better to remove this.

Kind regards,
Arjan

On Tue, Jul 11, 2017 at 10:57 AM, Darran Lofthouse <darran.lofthouse@...> wrote:
It probably has already gone by now but +1 to removal - I have seen bug reports in the past where code has performed checks like this and not realised it is only checking GET whilst allowing requests in for all other methods.


On Mon, 10 Jul 2017 at 15:15 Will Hopkins <will.hopkins@...> wrote:
Thanks, Arjan. I'll remove the single-arg method.

I think I'll leave the code snippet as is, only because time is short and there are still other changes to make.


On 07/10/2017 10:13 AM, arjan tijms wrote:
Hi,

That one method can be deleted if needed, it's just a convenience method really. 

About the example, it's about finding the balance between brevity and clarity. The intend was more to give an impression of the context the feature is being used in, not to be a fully working example with all imports, dependencies etc fully written out (for that the RI and specifically its test folder is more suited I think).

I wouldn't mind it being a bit more complete, but the intend at least was just to give an impression.

Kind regards,
Arjan Tijms




On Mon, Jul 10, 2017 at 3:16 PM, Will Hopkins <will.hopkins@...> wrote:
Arjan,

Do you have any comment on Guillermo's points below? In particular, I'm interested in your thoughts on the risk posed by the single-arg hasAccessToWebResource() method, and the suggestion to remove it and always require that methods be specified. That seems like a good idea to me. The other question is a minor point about the example JSF code.

Thanks,

Will


-------- Forwarded Message --------
Subject: Re: [javaee-security-spec] Public Review Draft Comments Guillermo González de Agüero
Date: Mon, 10 Jul 2017 01:59:05 -0400
From: Will Hopkins <will.hopkins@...>
To: javaee-security-spec@javaee.groups.io




On 05/26/2017 01:29 PM, Guillermo González de Agüero wrote:
Hi,

Here are my thoughts about the current draft of the spec. Some of them are very subjective and some are about rewording phrases that I may have misunderstood due to my poor English.
  • Page 4 - Contributor list has not been updated.
Updated (the full list was not available on the JSR page when the PDR was published).

  • General: links to external resources should have footnotes with the whole human readable url. Currently, printing the spec will make the links just disappear. For the same reason, links to sections of the spec should list the section they refer.
TODO
  • P5 - Terminology: JASPIC Java Authentication SPI for Containers <---- Suggestion: add a note that it is a JCP spec. Not needed, but complimentary.
Added.
  • p6 - application servers MUST provide a default mapping from group names to roles. [...] This default mapping MAY be overridden by proprietary configuration <----- I'd clarify that "may be overriden by EXPLICIT propierary configuration". As it currently reads out, GlassFish achieves this requirement by having a (disabled by default) option to do that mapping. Maybe that's the goal though and I'm just misunderstanding this. If that's the case, just ignore this point.
Added the word "explicit"

  • p6 - an application’s callers <--- Typo: an application's caller.
Plural seems correct to me -- does the application have just one caller?

  • p8 - An HttpAuthenticationMechanism is a CDI bean <---- Rewording: what do you think about "HttpAuthenticationMechanisms are CDI beans". Just personal taste. Talking about it in singular just reads strange to me, like if it could be only one.
I do think it reads better the way you suggest, but I've been trying to avoid pluralizing any type names that appear in the spec, since the type names themselves aren't plural and the plural form therefore doesn't refer any actual type. I do it in a few places, but trying to keep it to a minimum.

  • p8 - Only the validateRequest() method must be implemented; default behaviors are specified for the other two methods. <--- Rewording: I think "Only the validateRequest() method is required to be implemented" better expresses the idea.
Not sure I see much difference between "must be implemented" and "is required to be implemented", particularly given the explanatory text about default behavior ...

  • p10 - If neither the application nor the container makes an HttpAuthenticationMechanism available, then HttpAuthenticationMechanism is not used.  <--- The container is required to provide implementations of a variety of authentication mechanisms. The fact is that they are disabled by default, but they are always there. That phrase makes me think that "the container MAY NOT always provide an implementation", but what it's trying to say is that they may not be enabled. I'm not saying the sentence is not well written. It's probably me, but I see it a bit confusing.
See your point. I think it should be clear in context that the container is required to provide several implementations, and that this is about what's enabled, but I've attempted to clarify the language.

  • p11 - or each of BASIC and BASIC <-- I think that was already commented somewhere. I guess that was meant to be BASIC and FORM
Yup, already fixed.

  • p13 - getRequest(facesContext),getResponse(facesContext) <-- The code example calls to an ommited getRequest method, and also calls an statically imported (but with ommited imports) "withParams" method. Users may think both are statically imported or both ommited. I'd just inject the request and response objects. To gain some lines, I'd put the annotation and the property inline, e.g.:
                @Inject private HttpServletRequest;
                @Inject private HttpServletResponse;
This is Arjan's code -- I'd like him to comment before changing it.

  • p14 - Annotations are shown that use the LoginToContinue class, but that artifact is not shown nor the package is given. Users will be forced to go to the JavaDoc of the annotation to check what that class does.
Added some explanatory text.

  • p16 - and information sufficient to allow <-- Rewording: enough information?
Left as is.

  • p16 - perform only perform context- and environment-independent <-- Typo
Fixed.

  • p18 - that handle can handle <-- Typo
Fixed.

  • p20 - Methods of the IdentityStore interface are shown, but the public interface declaration is ommited. I'd add this declaration to be consistent with the rest of the code fragments.
Added declaration for IdentityStore, CredentialValidationResult, and IdentityStoreHandler.

  • p22 - A Java EE container MUST support built-in beans for the followingIdentityStoretypes, to beconfigured and made available via corresponding annotations <-- It may seem obvious, but where are these annotations expected to be used? I know they have to be used on classes discovered by the CDI runtime, but I would explicitly say that "implementations MUST support the use of these annotations on any CDI discovered type".
Chose not to add this because it is implicit and if I added it there I'd need to comb through the spec for any other place a similar statement would need to be made.

  • p25 - boolean hasAccessToWebResource(String resource) <-- This is a concern about the API. I'm afraid people may misuse this forgetting that it only tests the GET method. When you configure the security constraints of a servlet or url pattern and you don't set the affected methods, all methods are protected. Users may think that a value of "true" returned from this method means that the user is granted access to every method. I know this is about educating developers, but I'd personally drop this method and keep just the other one, that requires methods to be passed.
That's a good point; the other option would be to treat it as if all methods had been specified, rather than just get. That would eliminate the possibility of accidentally granting access to a method other than GET based on a true result from the call, because true would only be returned if access was granted to all methods. But it might be better to make the caller specify.

Unfortunately didn't see this earlier, would like to run it by Arjan.

Will


Regards,

Guillermo González de Agüero

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

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

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



Re: Default group to role mapping

Darran Lofthouse
 

I am probably missing this, where are we supposed to be casing this vote?


On Tue, 11 Jul 2017 at 01:54 <dblevins@...> wrote:
I'm late to the party and it's already resolved, but just throwing in my +1 for having the mapping enabled by default.

Incidentally, we also cast a yes vote on the Public Review Ballot :)


Re: Public Review Draft Comments Guillermo González de Agüero

Darran Lofthouse
 

It probably has already gone by now but +1 to removal - I have seen bug reports in the past where code has performed checks like this and not realised it is only checking GET whilst allowing requests in for all other methods.


On Mon, 10 Jul 2017 at 15:15 Will Hopkins <will.hopkins@...> wrote:
Thanks, Arjan. I'll remove the single-arg method.

I think I'll leave the code snippet as is, only because time is short and there are still other changes to make.


On 07/10/2017 10:13 AM, arjan tijms wrote:
Hi,

That one method can be deleted if needed, it's just a convenience method really. 

About the example, it's about finding the balance between brevity and clarity. The intend was more to give an impression of the context the feature is being used in, not to be a fully working example with all imports, dependencies etc fully written out (for that the RI and specifically its test folder is more suited I think).

I wouldn't mind it being a bit more complete, but the intend at least was just to give an impression.

Kind regards,
Arjan Tijms




On Mon, Jul 10, 2017 at 3:16 PM, Will Hopkins <will.hopkins@...> wrote:
Arjan,

Do you have any comment on Guillermo's points below? In particular, I'm interested in your thoughts on the risk posed by the single-arg hasAccessToWebResource() method, and the suggestion to remove it and always require that methods be specified. That seems like a good idea to me. The other question is a minor point about the example JSF code.

Thanks,

Will


-------- Forwarded Message --------
Subject: Re: [javaee-security-spec] Public Review Draft Comments Guillermo González de Agüero
Date: Mon, 10 Jul 2017 01:59:05 -0400
From: Will Hopkins <will.hopkins@...>
To: javaee-security-spec@javaee.groups.io




On 05/26/2017 01:29 PM, Guillermo González de Agüero wrote:
Hi,

Here are my thoughts about the current draft of the spec. Some of them are very subjective and some are about rewording phrases that I may have misunderstood due to my poor English.
  • Page 4 - Contributor list has not been updated.
Updated (the full list was not available on the JSR page when the PDR was published).

  • General: links to external resources should have footnotes with the whole human readable url. Currently, printing the spec will make the links just disappear. For the same reason, links to sections of the spec should list the section they refer.
TODO
  • P5 - Terminology: JASPIC Java Authentication SPI for Containers <---- Suggestion: add a note that it is a JCP spec. Not needed, but complimentary.
Added.
  • p6 - application servers MUST provide a default mapping from group names to roles. [...] This default mapping MAY be overridden by proprietary configuration <----- I'd clarify that "may be overriden by EXPLICIT propierary configuration". As it currently reads out, GlassFish achieves this requirement by having a (disabled by default) option to do that mapping. Maybe that's the goal though and I'm just misunderstanding this. If that's the case, just ignore this point.
Added the word "explicit"

  • p6 - an application’s callers <--- Typo: an application's caller.
Plural seems correct to me -- does the application have just one caller?

  • p8 - An HttpAuthenticationMechanism is a CDI bean <---- Rewording: what do you think about "HttpAuthenticationMechanisms are CDI beans". Just personal taste. Talking about it in singular just reads strange to me, like if it could be only one.
I do think it reads better the way you suggest, but I've been trying to avoid pluralizing any type names that appear in the spec, since the type names themselves aren't plural and the plural form therefore doesn't refer any actual type. I do it in a few places, but trying to keep it to a minimum.

  • p8 - Only the validateRequest() method must be implemented; default behaviors are specified for the other two methods. <--- Rewording: I think "Only the validateRequest() method is required to be implemented" better expresses the idea.
Not sure I see much difference between "must be implemented" and "is required to be implemented", particularly given the explanatory text about default behavior ...

  • p10 - If neither the application nor the container makes an HttpAuthenticationMechanism available, then HttpAuthenticationMechanism is not used.  <--- The container is required to provide implementations of a variety of authentication mechanisms. The fact is that they are disabled by default, but they are always there. That phrase makes me think that "the container MAY NOT always provide an implementation", but what it's trying to say is that they may not be enabled. I'm not saying the sentence is not well written. It's probably me, but I see it a bit confusing.
See your point. I think it should be clear in context that the container is required to provide several implementations, and that this is about what's enabled, but I've attempted to clarify the language.

  • p11 - or each of BASIC and BASIC <-- I think that was already commented somewhere. I guess that was meant to be BASIC and FORM
Yup, already fixed.

  • p13 - getRequest(facesContext),getResponse(facesContext) <-- The code example calls to an ommited getRequest method, and also calls an statically imported (but with ommited imports) "withParams" method. Users may think both are statically imported or both ommited. I'd just inject the request and response objects. To gain some lines, I'd put the annotation and the property inline, e.g.:
                @Inject private HttpServletRequest;
                @Inject private HttpServletResponse;
This is Arjan's code -- I'd like him to comment before changing it.

  • p14 - Annotations are shown that use the LoginToContinue class, but that artifact is not shown nor the package is given. Users will be forced to go to the JavaDoc of the annotation to check what that class does.
Added some explanatory text.

  • p16 - and information sufficient to allow <-- Rewording: enough information?
Left as is.

  • p16 - perform only perform context- and environment-independent <-- Typo
Fixed.

  • p18 - that handle can handle <-- Typo
Fixed.

  • p20 - Methods of the IdentityStore interface are shown, but the public interface declaration is ommited. I'd add this declaration to be consistent with the rest of the code fragments.
Added declaration for IdentityStore, CredentialValidationResult, and IdentityStoreHandler.

  • p22 - A Java EE container MUST support built-in beans for the followingIdentityStoretypes, to beconfigured and made available via corresponding annotations <-- It may seem obvious, but where are these annotations expected to be used? I know they have to be used on classes discovered by the CDI runtime, but I would explicitly say that "implementations MUST support the use of these annotations on any CDI discovered type".
Chose not to add this because it is implicit and if I added it there I'd need to comb through the spec for any other place a similar statement would need to be made.

  • p25 - boolean hasAccessToWebResource(String resource) <-- This is a concern about the API. I'm afraid people may misuse this forgetting that it only tests the GET method. When you configure the security constraints of a servlet or url pattern and you don't set the affected methods, all methods are protected. Users may think that a value of "true" returned from this method means that the user is granted access to every method. I know this is about educating developers, but I'd personally drop this method and keep just the other one, that requires methods to be passed.
That's a good point; the other option would be to treat it as if all methods had been specified, rather than just get. That would eliminate the possibility of accidentally granting access to a method other than GET based on a true result from the call, because true would only be returned if access was granted to all methods. But it might be better to make the caller specify.

Unfortunately didn't see this earlier, would like to run it by Arjan.

Will


Regards,

Guillermo González de Agüero

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

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

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


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

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


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

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.


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

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


Re: Default group to role mapping

Will Hopkins
 

Good to know, on both counts. :)

The consensus was to keep the mapping enabled by default, so that's what the spec still says.

Thanks,

Will


On 07/10/2017 08:42 PM, dblevins@... wrote:
I'm late to the party and it's already resolved, but just throwing in my +1 for having the mapping enabled by default.

Incidentally, we also cast a yes vote on the Public Review Ballot :)

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


Re: Default group to role mapping

David Blevins
 

I'm late to the party and it's already resolved, but just throwing in my +1 for having the mapping enabled by default.

Incidentally, we also cast a yes vote on the Public Review Ballot :)

361 - 380 of 736