Re: Welcome to the new JSR-375 mailing list


Will Hopkins
 

Arjan,

On 05/12/2017 04:45 PM, Arjan Tijms wrote:
Hi Will, 

On Fri, May 12, 2017 at 10:20 PM, Will Hopkins <will.hopkins@...> wrote:
What I'm saying is that the RememberMe functionality hasn't been spec'd yet. Although it has been in the API code, I had assumed it wouldn't be part of the spec since it wasn't mentioned in the EDR (which was published without javadoc).

By the JCP rules, everything that's in the API is also in the spec. In JSF for example there are quite an amount of things that are only in the Javadoc of the API and are then considered spec'd. For JSF 2.3, which we recently finished, I again double checked this.

Maybe it would help to reach out to Ed Burns (cc'ed) for this specific point, who is very experienced in this area and may be able to clarify this.

I understand that, and my intent is to publish javadoc corresponding to the PR draft, for exactly that reason.

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". (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.)

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

Some of those APIs may be reasonable to keep in the spec, but I don't think all of them are. On the plus side, the ones that don't stay in the API can become part of the RI, which may actually be the best status for them, as it means they'll get real world exposure to developers -- and to server vendors -- and can potentially be standardized in a follow-on JSR on the basis of real world experience.

Given that, and given the short timeline, I suggest we move it to the RI, and consider it for potential standardization in a follow-on JSR.

I don't think that should be needed. This was added relatively early to the spec, has received much positive feedback, and there are no problems with it that I know of. 

It doesn't appear in the PDF,  but as mentioned, not everything has to be put in there. If it's in the Javadoc it's considered part of the spec.

Nevertheless if you, or someone else in the EG, prefers a section for this in the EDR I can easily add this, but technically it should not be needed (should not be needed for the process).

(Re)moving it at this stage is probably risky, since the feature is also closely related to the form and custom form authentication mechanisms.

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

As you may know, WebLogic already does 1:1 role mapping is there's no specific configuration present and GF has a switch for it (but doesn't default to it).

OK, I was just wondering if there had been recent discussion of this. At first glance, your proposed wording seems reasonable, although I think it may involve some significant work on some platforms (including, potentially, WebLogic, as the code involved is not completely straightforward). I'll give that some thought.

Ok thanks!

In practice it seems that almost all platforms should hopefully not have much issues with this. It used to be quite different with GlassFish, WebSphere and WebLogic all mandating group to role mapping. Currently Liberty defaults to this default mapping when JASPIC is used and WebLogic when no explicit configuration is present. JBoss and TomEE never mandated this. GlassFish still mandates it, but has an option to switch it off already.

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.

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.