Re: Welcome to the new JSR-375 mailing list


Arjan Tijms
 

ps

>We did label it, as all of the API code was not only in a separate javax.* package (the one given to us by the JSR), but also in a separate API module within the project on the official GitHub repo.

Sorry, I think you meant which revision of the code, not which code at which place, my bad.

While the *exact* version wasn't tagged (yeah, we should have done that), the RememberMe feature was definitely in as that was done a long time ago and was not changed anytime close before or after the moment the EDR was published.

Kind regards,
Arjan Tijms

 




On Sat, May 13, 2017 at 1:44 AM, Arjan Tijms <arjan.tijms@...> wrote:
Hi,

On Fri, May 12, 2017 at 11:46 PM, Will Hopkins <will.hopkins@...> wrote:
I understand that, and my intent is to publish javadoc corresponding to the PR draft, for exactly that reason.

Okay, that's good, thanks!

 
My point is that we hadn't previously published the API code or javadoc. API code did exist at the time the EDR was published, but, although it existed, it was not published with the EDR, or incorporated by reference in any of the EDR materials. My assumption at the time, perhaps mistaken, was that it was therefore not part of "the EDR spec".

That's too bad indeed.

 
(For that matter, I don't believe we labeled the API code prior to publishing the EDR spec, so it's not clear which version of the code would correspond to the EDR.)

We did label it, as all of the API code was not only in a separate javax.* package (the one given to us by the JSR), but also in a separate API module within the project on the official GitHub repo.

Taken JSF again as an example; Mojarra does the same thing.

 
For the PDR, I'd like to fix that by publishing javadoc. To that end I started looking more closely at the API code, and noticed a number of significant interfaces that were not mentioned in the text of the EDR, and had not been discussed by the EG during the time I have been spec lead.

Indeed, but those were discussed and finished a long time ago, so during that interval there was no need to discuss these again.

 
Consequently, I hadn't spent much time thinking about them, and I don't think they've been very visible in the community at large, although the NLJUG does appear to have looked at the code.

NLJUG indeed looked at it and reviewed it, but I also published about the feature, e.g. here: http://arjan-tijms.omnifaces.org/p/whats-new-in-java-ee-security-api-10.html#33

I did a couple of reviews myself with developers in various teams and used Soteria (and specially the remember me feature) in quite a number of internal projects that have been running for quite some time now.

A number of community members has given very deep feedback on various JSR 375 and Soteria things (see the historical GitHub issues) including the session handling, which show this feature was definitely looked at by the community.

Finally there have been quite a number of presentations about JSR 375 where, if I remember correctly, this feature was presented and discussed too.

 
The form, custom form, and basic authentication mechanisms are part of what I think belongs in the RI. The servlet spec already requires support for form, custom form, basic, etc. -- these seem to me to be implementations of specific authentication mechanisms, not part of an API. Not only that, but containers already have to implement those mechanisms, so it's not clear what the value is in forcing a different implementation of the same feature.

The custom form specifically is not available in the Servlet spec, and that one is an important addition which aligns the form approach with platform services and APIs such as bean validation, CDI, and JSF, and modern programming techniques.

The regular form and basic authentication mechanisms are present not only for consistency reasons, but also make it both trivial and guaranteed to use the JSR 375 identity store with them, which wouldn't hold for the existing Servlet authentication mechanisms.

Maybe even more important, JSR 375 authentication mechanisms are fully CDI beans, which brings with them all the CDI features such as decorators, interceptors, alternatives and CDI extensions that can work with them.

It also gives a practical advantage of exercising the same code paths as user's custom authentication mechanisms would exercise. By using the Servlet ones, those paths would be partially different.
 
I'm fine with keeping these in the RI, but the API should be reserved for general-purpose APIs, rather than implementation details of for specific mechanisms. The real value of HttpAuthenticationMechanism is to allow applications to provide their own authentication mechanisms.

That too, but several default implementations are important just as well. JASPIC already allows applications to provide their own authentication mechanisms, but it's often seen as too abstract and not a complete solution.

If you compare this to e.g. JSF, you see that it defines the UIComponent interface for custom components, but also provides a small number of default components that all use that interface.

How both the provided HttpAuthenticationMechanisms and in JSF the provided UIComponents are implemented is an implementation detail. We were quite careful in making sure the actual bean type does not leak and that implementation details do not appear in the API.

To that end, the specific RememberMe usage for the implementation of the two form mechanisms is indeed an implementation detail, but moving it does mean an amount of work for the RI has to be done, which does take some time and re-testing for code that has already been tested in practice for well over a year.

Since there's no real problem with RememberMe, it just seems a bit wasteful to take this work upon us now, and we can better spend the little time that we have elsewhere IMHO.
 
It could be tricky in some platforms. For example, I'm actually not sure the WebLogic code behaves precisely that way -- it may also map user principals to roles by default. But I agree that it's good to have precision about the expected default, and that 1:1 mapping group->role seems like a good default rule.

Okay, thanks ;)

Kind regards,
Arjan Tijms


 

Regards,

Will



Kind regards,
Arjan Tijms



 



Kind regards,
Arjan Tijms

 

Will


On 05/12/2017 02:36 PM, Arjan Tijms wrote:
Hi Will,

Good to hear from you again, it has been a tad quiet at the list since the last EG call.

What are roughly speaking the API changes that still need to be done?

From the top of my head I think there's still one occurrence of getGroups returning a list. Spec wise we still need to say that the identity store getGroups method is subject to a Java SE security manager restriction.

After last call I applied a couple of other things as discussed during that call, such as the renaming and the check  in the handler that we overlooked previously.

One final thing that we should still spec is the 1:1 role mapping. We can either do this via a new element in web.xml, an annotation, both, or even something implicit (say spec text like: "If a JSR 375 authentication mechanism is configured, and not group to role mapping is not explicitly configured in a container specific way, the container *MUST* default to 1:1 group to role mapping")

Wdyt?

Kind regards,
Arjan Tijms




On Fri, May 12, 2017 at 7:37 PM, Will Hopkins <will.hopkins@...> wrote:
JSR-375 Experts and Users:

Welcome to the new JSR-375 mailing list (javaee-security-spec@...roups.io).

This list replaces the mailing lists previously hosted at java.net. There are no longer separate "experts" and "users" lists; this single list will be used for both purposes (which is a good simplification, since the old experts list was always forwarded to the users list anyway, creating lots of extra copies of emails). The java.net "issues" and "commits" lists will not be replicated here, but there are other mechanisms available to be notified of changes to the github source repos or issues lists.

I have been working on updating the spec for publication of the Public Review Draft. It's not quite done, but I plan to send an email later today detailing the major changes from the EDR and corresponding changes I expect to make to the API code.

Regards,

Will
-- 
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


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



Join javaee-security-spec@javaee.groups.io to automatically receive all group messages.