Welcome to the new JSR-375 mailing list


Will Hopkins
 

JSR-375 Experts and Users:

Welcome to the new JSR-375 mailing list (javaee-security-spec@javaee.groups.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


Arjan Tijms
 

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@javaee.groups.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
 

Hi Arjan,

Yes, it's been quiet -- I apologize for the long absence; in addition to a previously-planned week of vacation, I was given another assignment that took longer than anyone expected, and I kept my head down on that so as to get it done as quickly as I could. I've spent the last week coming back up to speed and preparing for the PR draft, which is now behind schedule.

As to the changes, I'd prefer to leave that for the upcoming email, to avoid spawning many different email threads. Mostly the changes relate to comments provided by those who reviewed the spec, points that seem to be the consensus of the EG, and also some points where there has not been consensus, but where I've made a decision based on differing points of view expressed by the EG (or community input). There are also a couple points on which I've made a unilateral decision simply because there isn't time to fully discuss things. The point of the email is to provide the EG with a least a little of time for feedback prior to publishing the PR.

I've also noticed that there are a number of interfaces in the API repo that don't correspond to things we've spec'd; the RememberMeIdentityStore, for example. I propose to move those out of the API (spec) to the RI.

What are you referring to re: 1:1 role mapping? Is that from the discussion on the ML after the last meeting?

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@javaee.groups.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


Arjan Tijms
 



On Fri, May 12, 2017 at 9:01 PM, Will Hopkins <will.hopkins@...> wrote:
Hi Arjan,

I've also noticed that there are a number of interfaces in the API repo that don't correspond to things we've spec'd; the RememberMeIdentityStore, for example. I propose to move those out of the API (spec) to the RI.

The RememberMeIdentityStore is crucial for the @RememberMe annotation, and has been spec'ed there.


 
What are you referring to re: 1:1 role mapping? Is that from the discussion on the ML after the last meeting?

The 1:1 role mapping refers to the fact that some Java EE products mandate groups to be mapped to roles. Without that mapping, nothing works.

This is *extremely* undesirable as it still requires server specific configuration, while the entire point of JSR 375 is to have security without any server specific configuration. This was early on recognised as an important thing to specify that it should not be done (using a switch or under certain circumstances), but we never actually did that.

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

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
 



On 05/12/2017 03:10 PM, Arjan Tijms wrote:


On Fri, May 12, 2017 at 9:01 PM, Will Hopkins <will.hopkins@...> wrote:
Hi Arjan,

I've also noticed that there are a number of interfaces in the API repo that don't correspond to things we've spec'd; the RememberMeIdentityStore, for example. I propose to move those out of the API (spec) to the RI.

The RememberMeIdentityStore is crucial for the @RememberMe annotation, and has been spec'ed there.


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). 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.
 
What are you referring to re: 1:1 role mapping? Is that from the discussion on the ML after the last meeting?

The 1:1 role mapping refers to the fact that some Java EE products mandate groups to be mapped to roles. Without that mapping, nothing works.

This is *extremely* undesirable as it still requires server specific configuration, while the entire point of JSR 375 is to have security without any server specific configuration. This was early on recognised as an important thing to specify that it should not be done (using a switch or under certain circumstances), but we never actually did that.

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.


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


Arjan Tijms
 

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

 
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.

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
 

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


Arjan Tijms
 

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



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




Will Hopkins
 

Right, I was referring to the revision of the code.

I understand that RememberMe has been in the code for some time, and that javadoc is considered part of the spec. I made a couple of assumptions that, in hindsight, were unfortunate. I assumed that:
  • Only a specific version of javadoc, actually published in conjunction with a version of the spec, would be considered part of that spec (and I still feel that's a legitimate view).
  • Any significant/important features would at least be mentioned in the spec, even if detailed description was left to javadoc. (I continue to think that any non-trivial feature should be described in the spec, even if javadoc is technically sufficient.)
As a result, I approached the task as getting the spec right, then making the javadoc match the spec, and I didn't spend enough time looking carefully at the existing API code (which had originally been co-mingled with the RI code, so might have included code that really belonged with the RI). Given that I wasn't involved in the earlier discussions of RememberMe and related features, they weren't mentioned in the EDR, and they didn't come up in the related EG discussions, I didn't realize that those features were part of the proposed API.

Now the question is what to do with them. If it were straightforward to just include them, I would, but I think there are some significant technical questions to resolve. I'll address them in a separate thread.

Regards,

Will

On 05/12/2017 07:55 PM, Arjan Tijms wrote:
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



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


Arjan Tijms
 

Hi,

On Mon, May 15, 2017 at 6:19 AM, Will Hopkins <will.hopkins@...> wrote:

  • Any significant/important features would at least be mentioned in the spec, even if detailed description was left to javadoc. (I continue to think that any non-trivial feature should be described in the spec, even if javadoc is technically sufficient.)
It's two ways of thinking about it indeed, one is basically: "the api is the spec, and the pdf only clarifies cross cutting concerns or things that woud be out of place in Javadoc", while the other is what you described.

The JSR process seemingly allows both approaches, which I admit can be confusing.

Nevertheless, the EDR is just a draft of course, and there's no specific requirement that it includes everything that's going to be in the public review.

If needed I can free up some time today and add a section for the feature anyway and/or update the Javadoc to address anything that may be unclear at this point. There went a of lot of thinking, testing and discussion in many things that are now in the API. For feeling would be that if anything was unclear at this point it would largely be a matter of just more carefully writing down any of those decisions being made.

Kind regards,
Arjan Tijms



 
As a result, I approached the task as getting the spec right, then making the javadoc match the spec, and I didn't spend enough time looking carefully at the existing API code (which had originally been co-mingled with the RI code, so might have included code that really belonged with the RI). Given that I wasn't involved in the earlier discussions of RememberMe and related features, they weren't mentioned in the EDR, and they didn't come up in the related EG discussions, I didn't realize that those features were part of the proposed API.

Now the question is what to do with them. If it were straightforward to just include them, I would, but I think there are some significant technical questions to resolve. I'll address them in a separate thread.

Regards,

Will


On 05/12/2017 07:55 PM, Arjan Tijms wrote:
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



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



Will Hopkins
 

Arjan, et al.:

On 05/12/2017 07:44 PM, Arjan Tijms wrote:

On Fri, May 12, 2017 at 11:46 PM, Will Hopkins <will.hopkins@...> wrote:
 
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.

Can you explain more about that? What does Custom Form do that's not already available (apart from leveraging IdentityStore), and what benefits does the alignment bring for apps?

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.

Support for IdentityStores could be achieved more simply and directly (from a container implementer's POV), by simply mandating that FORM and BASIC auth methods (perhaps CERT as well) use application-provided IdentityStores when present.

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.

I do see value in that, although I'm not sure how often decorators or interceptors would be needed for BASIC or FORM, in particular, and it would always be possible for an app developer to write the appropriate HAM -- or leverage an RI implementation. The calculus would be different if we had more time, but it doesn't seem essential (to me) that they be specified as part of the API.

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.

Any given app is likely to have one or the other, not both, and custom schemes are, by definition, custom.

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.

The point of HAM is that it eliminates the most of the complexity, overcoming that barrier. BASIC auth is BASIC auth, regardless of where/how implemented, as long as it works. The value of something like HAM is to allow application developers to provide an auth mechanism when the standard mechanisms aren't sufficient.

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.

The servlet container already provides default implementations of FORM and BASIC, just not ones that leverage HAM. Does JSF provide multiple implementations of each default UIComponent?

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.

I have some architectural concerns about the general approach of implementing HAMs for BASIC and FORM auth, and with RememberMe in particular.

It's possible that I don't fully understand the intent of RememberMe, but it looks to me like what it's really doing is session management, not authentication. The RememberMeIdentityStore isn't really an identity store at all, it's a cache of authenticated users. If we really wanted to specify session management, we could do so, but the servlet spec already says how servlet containers should do session management. Shouldn't we integrate with that existing capability, rather than building a redundant, and less capable, feature on top of the existing feature? Do we really want two session cookies rather than one? Have we specified it fully enough? How does RememberMe ensure that the cookies it issues are protected against session stealing attacks? Do we require that the cookie is marked secure? If so, how does it work if an authenticated user makes a request over a non-SSL connection? Existing servlet containers have worked through these kinds of issues over many years, and are generally pretty robust at this point; we should leverage their existing capabilities.

Similarly the FORM and BASIC implementations, if left in the API, should be required to integrate with container session management, so that behavior is uniform for apps that use HAM and apps that don't. Authentication is authentication; session management is different, and mostly (though not entirely) orthogonal.

In part where I'm coming from is that I see a difference between a framework that's mean to run in a wide variety of platforms, some of which may be Java EE containers, and some of which may not, and a JSR, which is explicitly meant to be *part* of the Java EE platform, and fully integrated with it -- not merely layered on top. I think we should be specifying where JSR-375 needs to integrate with the servlet container, not how it can duplicate or re-implement existing functionality.

Those are my initial thoughts, anyway. I do see the benefits of the fact that HAMs are CDI beans, but, at a minimum, I think there's complexity here, and some questions that need to be resolved, and little or no time to do so. That's probably my fault, but we are where we are.

Thoughts?

Will

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


Will Hopkins
 

Thanks for the offer -- that may be helpful -- but I think there are open technical questions to resolve first. Just sent mail on that topic.

On 05/15/2017 12:33 AM, Arjan Tijms wrote:
Hi,

On Mon, May 15, 2017 at 6:19 AM, Will Hopkins <will.hopkins@...> wrote:

  • Any significant/important features would at least be mentioned in the spec, even if detailed description was left to javadoc. (I continue to think that any non-trivial feature should be described in the spec, even if javadoc is technically sufficient.)
It's two ways of thinking about it indeed, one is basically: "the api is the spec, and the pdf only clarifies cross cutting concerns or things that woud be out of place in Javadoc", while the other is what you described.

The JSR process seemingly allows both approaches, which I admit can be confusing.

Nevertheless, the EDR is just a draft of course, and there's no specific requirement that it includes everything that's going to be in the public review.

If needed I can free up some time today and add a section for the feature anyway and/or update the Javadoc to address anything that may be unclear at this point. There went a of lot of thinking, testing and discussion in many things that are now in the API. For feeling would be that if anything was unclear at this point it would largely be a matter of just more carefully writing down any of those decisions being made.

Kind regards,
Arjan Tijms



 
As a result, I approached the task as getting the spec right, then making the javadoc match the spec, and I didn't spend enough time looking carefully at the existing API code (which had originally been co-mingled with the RI code, so might have included code that really belonged with the RI). Given that I wasn't involved in the earlier discussions of RememberMe and related features, they weren't mentioned in the EDR, and they didn't come up in the related EG discussions, I didn't realize that those features were part of the proposed API.

Now the question is what to do with them. If it were straightforward to just include them, I would, but I think there are some significant technical questions to resolve. I'll address them in a separate thread.

Regards,

Will


On 05/12/2017 07:55 PM, Arjan Tijms wrote:
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



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


Arjan Tijms
 

Hi,

On Mon, May 15, 2017 at 7:36 AM, Will Hopkins <will.hopkins@...> wrote:

Can you explain more about that? What does Custom Form do that's not already available (apart from leveraging IdentityStore), and what benefits does the alignment bring for apps?

With the existing form authentication mechanism, an application can start the authentication dialog by calling HttpServletRequest#authenticate, but it can't continue it in this way after having collected the credentials.

Custom form provides the full form algorithm / process such as specified by the Servlet spec, with the small but essential difference that  the "command" to continue the authentication dialog after the mechanism calls out to the application can be done programmatically (via Java code) instead of posting back to the virtual URL /j_security_check with post parameters j_username and j_password.

This is important because in modern Java EE applications you often want to bind those credentials to a CDI bean, then use existing bean validation to validate some basics (password not null, password long enough, etc) and render an error message via JSF if anything was wrong.

There's a test/example of that in the RI:

First we have a view with credentials bound via EL to a CDI bean, and the submit action bound to a login method on a CDI bean:

 <h:messages />
    
    <body>
        <p>
            Login to continue
        </p>
    
         <form jsf:id="form">
            <p>
                <strong>Username </strong> 
                <input jsf:id="username" type="text" jsf:value="#{loginBacking.username}" />
            </p>
            <p>
                <strong>Password </strong> 
                <input jsf:id="password" type="password" jsf:value="#{loginBacking.password}" />
            </p>
            <p>
                <input type="submit" value="Login" jsf:action="#{loginBacking.login}" />
            </p>
        </form>
    
    </body>


Then the CDI bean has bean validation annotations applied:

@Named
@RequestScoped
public class LoginBacking {

    @NotNull
    @Size(min = 3, max = 15, message="Username must be between 3 and 15 characters")
    private String username;
    
    @NotNull
    @Size(min = 5, max = 50, message="Password must be between 5 and 50 characters")
    private String password;

    // ...
}

And then the login method can continue the authentication dialog:

public void login() {
         
        Credential credential = new UsernamePasswordCredential(username, new Password(password));
        
        AuthenticationStatus status = securityContext.authenticate(
            getRequest(context),
            getResponse(context), 
            withParams()
                .credential(credential));
        
        if (status.equals(IN_PROGRESS)) {
            context.responseComplete();
        } else if (status.equals(FAILURE)) {
            addError(context, "Authentication failed");
        }

}

This modern approach to Java EE programming is not possible with the existing form mechanism, where posting back to /j_security_check is often seen as old and clunky and certainly not capable of easily leveraging existing code in CDI, EL, BeanValidation and JSF.

 
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.

Support for IdentityStores could be achieved more simply and directly (from a container implementer's POV), by simply mandating that FORM and BASIC auth methods (perhaps CERT as well) use application-provided IdentityStores when present.

This is certainly an option, and the reverse has actually been proposed as well (but not acted upon) that the HAM will be able to use a container specific IdentityStore in some way (a bridge IdentityStore would be one way to achieve this).

That however doesn't help with the consistency and CDI things.

You could see it the other way around though; a full container does not necessarily have to implement those two mechanisms twice. From the point of the spec the JSR 375 provided FORM is NOT required to be implemented fully, it just says this:

/**
 * Annotation used to define a container {@link AuthenticationMechanism} that implements
 * FORM authentication mechanism as defined by the Servlet spec and make that implementation
 * available as an enabled CDI bean.
 *
 */
@Retention(RUNTIME)
@Target(TYPE)
public @interface FormAuthenticationMechanismDefinition {
 
    @Nonbinding
    LoginToContinue loginToContinue();
    
}

The RI for convenience implements it from scratch, but full containers are only required to look at this annotation for the configuration of the existing (servlet) mechanism and expose a CDI bean that wraps or delegates to it.

Your concern is valid, but we took this into account earlier. I think we had discussions with Alex and perhaps David about this way in the beginning. That's why it says "as defined by the Servlet spec". A lot of thought went onto that seemingly simple fragment of text.

 
Any given app is likely to have one or the other, not both, and custom schemes are, by definition, custom.

Here I meant from a practical EE product testing and implementation perspective. If a lot of tests that the implementors do for BASIC and FORM directly go to the Servlet mechanism, they don't test the CDI "wrapper/delegation" code paths. A separate custom mechanism would have to be added to the test suite and only that tests those paths.

As I've seen with JASPIC, this rarely happens, resulting in 4 long years of reporting and fixing various bugs.

Applications that use FORM via the CDI wrapper would also implicitly test that CDI wrapper, so when it comes time for someone to use a custom authentication mechanism, the chance that these paths have already been tested via the supplied mechanisms is a lot higher. 

 
The servlet container already provides default implementations of FORM and BASIC, just not ones that leverage HAM. Does JSF provide multiple implementations of each default UIComponent?

You mean if JSF provides a component already present in another spec?

In that regards, it's a full yes.

JSP and JSTL define a c:out tag, which is used to render output.

JSF defines an h:outputText tag, which does the same thing but more aligned with how the other tags (and associated components) work in JSF. Here too, especially when used on JSP, an implementation would not necessarily have to code up the same output code twice but could have the h:outputText tag as a front for the code in c:out.

 
I have some architectural concerns about the general approach of implementing HAMs for BASIC and FORM auth, and with RememberMe in particular.

It's possible that I don't fully understand the intent of RememberMe, but it looks to me like what it's really doing is session management, not authentication.

This is not entirely correct. What it does is effectively exchange credentials for a token, and the token is used to authenticate the caller at every request when no (valid) HTTP session is present.

This is currently defined in the spec as follows:

 * For the remember me function the credentials provided by the caller are exchanged for a token
 * which is send to the user as the value of a cookie, in a similar way to how the HTTP session ID is send.
 * It should be realized that this token effectively becomes the credential to establish the caller's
 * identity within the application and care should be taken to handle and store the token securely. E.g.
 * by using this feature with a secure transport (SSL/https), storing a strong hash instead of the actual
 * token, and implementing an expiration policy. 

 
The RememberMeIdentityStore isn't really an identity store at all, it's a cache of authenticated users.

Not necessarily. A simple implementation of the interface could be just a cache indeed, but a "real" IdentityStore could also just be effectively a cache.

How a RememberMeIdentityStore is implemented is up to the user. An implementation could say go to a local filesystem based DB if the token is not older than a certain amount of time, and force revalidation at a remote origin authentication server if it's older. Tokens could be automatically expired and/or revoked explicitly.
 
If we really wanted to specify session management, we could do so, but the servlet spec already says how servlet containers should do session management. Shouldn't we integrate with that existing capability, rather than building a redundant, and less capable, feature on top of the existing feature?

The Servlet spec does not have any specification for this kind of session management. The HTTP session is a very broad type of session that brings with it a lot of other things, but mostly memory consumption. That's why the HTTP session has to expire after a relatively short amount of time.

The remember me token is longer lived (by definition, basically) and has no associated concept of consuming server resources. As mentioned above, an application can authenticate users using the token by going to a database or any other store.

The entire point of the token is to be able to live longer than the http session. If it would directly use the http session it would not even be needed (this is basically the key insight).

A typical pipeline as defined by priorities in a CDI interceptor chain in JSR 375 is to do the following in order:

1. Check the HTTP session if the caller is authenticated, if so use this identity
2. If no details in the HTTP session, check if a remember me token is present, if so use this to authenticate the user
3. If no remember me token is present, start the lowest level authentication mechanism (e.g. FORM).

So with both HTTP sessions and RememberMe activated, the very first request would hit 3). The second and following requests within that HTTP session would hit 1).

Then when the HTTP session expires and the caller does a request again, it would hit 2), and then for all following requests within the new HTTP session it would hit 1) again.

 
Do we really want two session cookies rather than one?

Yes, absolutely, since the expiration policy of the two cookies are totally different. One is longer lived and MUST NOT be removed when the browser closes, while the other is shorted lived and MUST be removed when the browser closes.
 
Have we specified it fully enough? How does RememberMe ensure that the cookies it issues are protected against session stealing attacks? Do we require that the cookie is marked secure? If so, how does it work if an authenticated user makes a request over a non-SSL connection?

These are good questions and the answer is that it's basically the same as for the JSESSIONID cookie. Servlet containers basically give the user 2 options for this as evidenced by the cookie-config:

<cookie-config>
    <http-only>true</http-only>
    <secure>true</secure>
</cookie-config>

In the JSR 375 case the spec warns for this case by suggesting that "secure" should be required "by using this feature with a secure transport (SSL/https", but it would probably be a good idea to default these two settings to be set to true. The only reason for secure not being set to true is localhost development, where you often don't have a secure connection to your dev server.

The cookie handler in the RI already sets http only to true btw:

public class CookieHandler {

public static void saveCookie(HttpServletRequest request, HttpServletResponse response, String name, String value, Integer maxAge) {
Cookie cookie = new Cookie(name, value);
if (maxAge != null) {
cookie.setMaxAge(maxAge);
}
cookie.setHttpOnly(true);
cookie.setPath(isEmpty(request.getContextPath())? "/" : request.getContextPath());

response.addCookie(cookie);
}

But I think it would be good to make the spec a bit more strict here, thanks for mentioning this concern!


 
Similarly the FORM and BASIC implementations, if left in the API, should be required to integrate with container session management, so that behavior is uniform for apps that use HAM and apps that don't. Authentication is authentication; session management is different, and mostly (though not entirely) orthogonal.

In this case it's simply a layer underneath the existing session, like layers in a memory hierarchy. So as explained above it's http session -> token store -> original store (and mechanism).

 
In part where I'm coming from is that I see a difference between a framework that's mean to run in a wide variety of platforms, some of which may be Java EE containers, and some of which may not, and a JSR, which is explicitly meant to be *part* of the Java EE platform, and fully integrated with it -- not merely layered on top. I think we should be specifying where JSR-375 needs to integrate with the servlet container, not how it can duplicate or re-implement existing functionality.

I understand your concerns, but as explained above it's not duplicating or re-implementating functionality. By its very definition a "remember me" token must live outside the http session, but it only comes into play if the http session is not there anymore. Perhaps that's where the confusion comes from. If the http session is active, the mechanisms you mention work with the http session as they normally would.
 
Those are my initial thoughts, anyway. I do see the benefits of the fact that HAMs are CDI beans, but, at a minimum, I think there's complexity here, and some questions that need to be resolved, and little or no time to do so. That's probably my fault, but we are where we are.

Thoughts?

We are where we are indeed. I hope to have answered most questions, and that we can amend the spec today where needed. Especially requiring secure and httponly to default to true would probably be a good thing to add to the spec.

Thanks for your thorough review!

Kind regards,
Arjan Tijms


 


Will

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



Will Hopkins
 

Hi Arjan,

On 05/15/2017 07:18 AM, Arjan Tijms wrote:
Hi,

On Mon, May 15, 2017 at 7:36 AM, Will Hopkins <will.hopkins@...> wrote:

Can you explain more about that? What does Custom Form do that's not already available (apart from leveraging IdentityStore), and what benefits does the alignment bring for apps?

With the existing form authentication mechanism, an application can start the authentication dialog by calling HttpServletRequest#authenticate, but it can't continue it in this way after having collected the credentials.

Custom form provides the full form algorithm / process such as specified by the Servlet spec, with the small but essential difference that  the "command" to continue the authentication dialog after the mechanism calls out to the application can be done programmatically (via Java code) instead of posting back to the virtual URL /j_security_check with post parameters j_username and j_password.

This is important because in modern Java EE applications you often want to bind those credentials to a CDI bean, then use existing bean validation to validate some basics (password not null, password long enough, etc) and render an error message via JSF if anything was wrong.

There's a test/example of that in the RI:
[...]
Then the CDI bean has bean validation annotations applied:

@Named
@RequestScoped
public class LoginBacking {

    @NotNull
    @Size(min = 3, max = 15, message="Username must be between 3 and 15 characters")
    private String username;
    
    @NotNull
    @Size(min = 5, max = 50, message="Password must be between 5 and 50 characters")
    private String password;

    // ...
}
[...]
This modern approach to Java EE programming is not possible with the existing form mechanism, where posting back to /j_security_check is often seen as old and clunky and certainly not capable of easily leveraging existing code in CDI, EL, BeanValidation and JSF.

I agree that the existing mechanisms aren't modern, and that there may be use cases where developers want or need to modify the process. That said, I think the legitimate use cases are probably few and far between. Existing implementations of FORM and BASIC have been refined over the years, such that they are robust and handle most reasonable requirements.

The example you provide above demonstrates the capability, but doesn't demonstrate the need -- in my view, intervening to check username/password length before actually validating the credentials is misguided on separation of duties grounds -- only the identity store can authoritatively say whether the credentials are valid or not -- and is potentially insecure. Best practice when validating credentials is to return "login failed" for all failure cases, regardless of the cause. Returning a different error for bad password vs. invalid user -- or for username/password too short -- reveals information that an attacker could use to break into a system. Timing differences between the two code paths could also reveal information helpful to an attacker.

I have not heard feedback from our customers that they need or want to extend the functionality provided by FORM or BASIC authentication in WebLogic.

Also -- is it not possible to reference a CDI bean, or perform validation on j_username/j_password in some other way, from a login form using the existing mechanism?

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.

Support for IdentityStores could be achieved more simply and directly (from a container implementer's POV), by simply mandating that FORM and BASIC auth methods (perhaps CERT as well) use application-provided IdentityStores when present.

This is certainly an option, and the reverse has actually been proposed as well (but not acted upon) that the HAM will be able to use a container specific IdentityStore in some way (a bridge IdentityStore would be one way to achieve this).

My proposal would be specify that the container should use an application-supplied IdentityStore for FORM/BASIC if present, but also that the container is permitted to override an application-provided IdentityStore with one of its own. i spent some time reading the CDI spec, and it appears to me that this would be possible by observing events during bean discovery and replacing the application's bean with a container bean when the appropriate event is fired -- I'm still not sure which event is the most appropriate one, though -- I'd be interested in your thoughts, as you clearly know CDI better than I.

That however doesn't help with the consistency and CDI things.

Agreed, and I'm generally a fan of consistency. In this case, the question in my mind is whether consistency alone is a good enough reason to require containers to provide this functionality when it would impose an implementation cost on container vendors and there is no clear functional requirement driving it. Vendors could always choose to provide the functionality, or even re-implement their existing FORM/BASIC support as HAMs, if it were present in the RI.

You could see it the other way around though; a full container does not necessarily have to implement those two mechanisms twice. From the point of the spec the JSR 375 provided FORM is NOT required to be implemented fully, it just says this:

/**
 * Annotation used to define a container {@link AuthenticationMechanism} that implements
 * FORM authentication mechanism as defined by the Servlet spec and make that implementation
 * available as an enabled CDI bean.
 *
 */
@Retention(RUNTIME)
@Target(TYPE)
public @interface FormAuthenticationMechanismDefinition {
 
    @Nonbinding
    LoginToContinue loginToContinue();
    
}

The RI for convenience implements it from scratch, but full containers are only required to look at this annotation for the configuration of the existing (servlet) mechanism and expose a CDI bean that wraps or delegates to it.

Refactoring FORM/BASIC to expose it via CDI may or may not be a trivial exercise for any given container vendor. If significant refactoring is involved, vendors may choose to provide two implementations instead. The requirement to also support the custom form API might also be a factor.

Your concern is valid, but we took this into account earlier. I think we had discussions with Alex and perhaps David about this way in the beginning. That's why it says "as defined by the Servlet spec". A lot of thought went onto that seemingly simple fragment of text.

Good to know. Does he existing RI implementation meet that requirement?

Any given app is likely to have one or the other, not both, and custom schemes are, by definition, custom.

Here I meant from a practical EE product testing and implementation perspective. If a lot of tests that the implementors do for BASIC and FORM directly go to the Servlet mechanism, they don't test the CDI "wrapper/delegation" code paths. A separate custom mechanism would have to be added to the test suite and only that tests those paths.

As I've seen with JASPIC, this rarely happens, resulting in 4 long years of reporting and fixing various bugs.

Applications that use FORM via the CDI wrapper would also implicitly test that CDI wrapper, so when it comes time for someone to use a custom authentication mechanism, the chance that these paths have already been tested via the supplied mechanisms is a lot higher.

If a vendor chooses to provide two implementations of FORM/BASIC, that problem will still remain. Mandating functionality to drive testing seems like the tail wagging the dog; a focus on a robust TCK seems like a better approach.
 
The servlet container already provides default implementations of FORM and BASIC, just not ones that leverage HAM. Does JSF provide multiple implementations of each default UIComponent?

You mean if JSF provides a component already present in another spec?

In that regards, it's a full yes.

JSP and JSTL define a c:out tag, which is used to render output.

JSF defines an h:outputText tag, which does the same thing but more aligned with how the other tags (and associated components) work in JSF. Here too, especially when used on JSP, an implementation would not necessarily have to code up the same output code twice but could have the h:outputText tag as a front for the code in c:out.

I don't know these technologies well enough to have an informed opinion on whether h:outputText is duplicative of c:out, but it does seem that JSF is layered on JSP/JSTL in a way that, in my conception, JSR-375 is not layered on Servlet. Although JSR-375 and Servlet are different specs, they are tightly integrated, rather than one being simply layered on top of the other.

I have some architectural concerns about the general approach of implementing HAMs for BASIC and FORM auth, and with RememberMe in particular.

It's possible that I don't fully understand the intent of RememberMe, but it looks to me like what it's really doing is session management, not authentication.

This is not entirely correct. What it does is effectively exchange credentials for a token, and the token is used to authenticate the caller at every request when no (valid) HTTP session is present.

This is currently defined in the spec as follows:

 * For the remember me function the credentials provided by the caller are exchanged for a token
 * which is send to the user as the value of a cookie, in a similar way to how the HTTP session ID is send.
 * It should be realized that this token effectively becomes the credential to establish the caller's
 * identity within the application and care should be taken to handle and store the token securely. E.g.
 * by using this feature with a secure transport (SSL/https), storing a strong hash instead of the actual
 * token, and implementing an expiration policy. 

 
The RememberMeIdentityStore isn't really an identity store at all, it's a cache of authenticated users.

Not necessarily. A simple implementation of the interface could be just a cache indeed, but a "real" IdentityStore could also just be effectively a cache.

How a RememberMeIdentityStore is implemented is up to the user. An implementation could say go to a local filesystem based DB if the token is not older than a certain amount of time, and force revalidation at a remote origin authentication server if it's older. Tokens could be automatically expired and/or revoked explicitly.

I still feel like RememberMe is not well-defined. If it's really a session management facility, then it's under-specified, it shouldn't be delegating to an IdentityStore, and there's no clear rationale for implementing a new session management capability in addition to what the container already provides. Existing container session management is almost certainly more robust and more secure than RememberMe. I would argue that long-lived sessions are a bad idea (as distinct from long-lived authentication tokens), but existing containers allow for configurable session lifetimes.

If it's really an authentication token service, then, again, it's underspecified. There are certainly use cases for long-lived tokens, but the specifics of the token matter. OAuth tokens are one example, and are well-specified in terms of token format and content, and the trust models that apply to various types of OAuth tokens and various use cases. Importantly, OAuth tokens use encryption and digital signatures to provide confidentiality, integrity, and trust in the issuer. None of that is specified here because no specific token type (or token protocol) is specified.

The best way to think about RememberMe is probably in terms of a generic mechanism for token issuance, and that seems to be the intent of RememberMeIdentityStore. But it's not fully "plumbed" -- since HAMs are supposed to interact only with IdentityStoreHandler, not IdentityStore, shouldn't IdentityStoreHandler expose generateLoginToken()? Also, the removeLoginToken() method is more consistent with a session model than a token issuance model -- issued tokens, especially long-lived ones, are typically not cached because there's no need to -- they can be cryptographically verified, and they contain all the information needed for user identification and authentication. Lastly, the RememberMe annotation provides very little configurability -- it only supports cookies (not, e.g., HTTP headers, or form fields), and even for cookies allows configuration only for cookie name and lifetime.

The FORM and BASIC annotations make sense to me -- I still have reservations about including them, but I understand the value proposition, and how they're intended to work. RememberMe doesn't seem sufficiently well thought out yet.

If we really wanted to specify session management, we could do so, but the servlet spec already says how servlet containers should do session management. Shouldn't we integrate with that existing capability, rather than building a redundant, and less capable, feature on top of the existing feature?

The Servlet spec does not have any specification for this kind of session management. The HTTP session is a very broad type of session that brings with it a lot of other things, but mostly memory consumption. That's why the HTTP session has to expire after a relatively short amount of time.

The remember me token is longer lived (by definition, basically) and has no associated concept of consuming server resources. As mentioned above, an application can authenticate users using the token by going to a database or any other store.

The entire point of the token is to be able to live longer than the http session. If it would directly use the http session it would not even be needed (this is basically the key insight).

As noted above, that sounds more like a long-lived authentication token than a session. Having given it some more thought, I think RememberMe is not really session management or token-based authentication, it's token issuance, but I think it needs to be conceptualized as such, and more fully specified, before it's ready for inclusion in the spec.

A typical pipeline as defined by priorities in a CDI interceptor chain in JSR 375 is to do the following in order:

1. Check the HTTP session if the caller is authenticated, if so use this identity
2. If no details in the HTTP session, check if a remember me token is present, if so use this to authenticate the user
3. If no remember me token is present, start the lowest level authentication mechanism (e.g. FORM).

So with both HTTP sessions and RememberMe activated, the very first request would hit 3). The second and following requests within that HTTP session would hit 1).

Then when the HTTP session expires and the caller does a request again, it would hit 2), and then for all following requests within the new HTTP session it would hit 1) again.

I think a key conceptual difference between what happens in step 2 and what happens in step 3. Step two is the container identifying an authentication token and using it to authenticate the user. The function/behavior of step 3 depends on whether FORM is just an alternative authentication mechanism (because multiple acceptable mechanisms are available), or whether step 3 is really a redirect to a token issuance service. (Not necessarily a literal redirect, but a logical redirect.)

Do we really want two session cookies rather than one?

Yes, absolutely, since the expiration policy of the two cookies are totally different. One is longer lived and MUST NOT be removed when the browser closes, while the other is shorted lived and MUST be removed when the browser closes.

I think the answer is that one is a session cookie and the other is not (it's an authentication token). If the model is really token issuance, the fact that only cookies are supported seems like a bit limitation.

Have we specified it fully enough? How does RememberMe ensure that the cookies it issues are protected against session stealing attacks? Do we require that the cookie is marked secure? If so, how does it work if an authenticated user makes a request over a non-SSL connection?

These are good questions and the answer is that it's basically the same as for the JSESSIONID cookie. Servlet containers basically give the user 2 options for this as evidenced by the cookie-config:

<cookie-config>
    <http-only>true</http-only>
    <secure>true</secure>
</cookie-config>

In the JSR 375 case the spec warns for this case by suggesting that "secure" should be required "by using this feature with a secure transport (SSL/https", but it would probably be a good idea to default these two settings to be set to true. The only reason for secure not being set to true is localhost development, where you often don't have a secure connection to your dev server.

The cookie handler in the RI already sets http only to true btw:

public class CookieHandler {

public static void saveCookie(HttpServletRequest request, HttpServletResponse response, String name, String value, Integer maxAge) {
Cookie cookie = new Cookie(name, value);
if (maxAge != null) {
cookie.setMaxAge(maxAge);
}
cookie.setHttpOnly(true);
cookie.setPath(isEmpty(request.getContextPath())? "/" : request.getContextPath());

response.addCookie(cookie);
}

But I think it would be good to make the spec a bit more strict here, thanks for mentioning this concern!

Agreed, but an application with both http and https resources has more complicated requirements, given that you don't want users to have to authenticate twice, and given that the servlet spec mandates that the same session be shared across all of an application's resources, both http and https. The presense of multiple session cookies, representing sessions with different lifetimes complicates the situation even more, and potentially presents opportunities for session stealing when login events occur or tokens are refreshed/re-issued.

Similarly the FORM and BASIC implementations, if left in the API, should be required to integrate with container session management, so that behavior is uniform for apps that use HAM and apps that don't. Authentication is authentication; session management is different, and mostly (though not entirely) orthogonal.

In this case it's simply a layer underneath the existing session, like layers in a memory hierarchy. So as explained above it's http session -> token store -> original store (and mechanism).

 
In part where I'm coming from is that I see a difference between a framework that's mean to run in a wide variety of platforms, some of which may be Java EE containers, and some of which may not, and a JSR, which is explicitly meant to be *part* of the Java EE platform, and fully integrated with it -- not merely layered on top. I think we should be specifying where JSR-375 needs to integrate with the servlet container, not how it can duplicate or re-implement existing functionality.

I understand your concerns, but as explained above it's not duplicating or re-implementating functionality. By its very definition a "remember me" token must live outside the http session, but it only comes into play if the http session is not there anymore. Perhaps that's where the confusion comes from. If the http session is active, the mechanisms you mention work with the http session as they normally would.

Agree. I have a better understanding of the motivation for FORM and BASIC annotations/HAMs now. I think I understand RememberMe better as well, but I feel it still needs significant work before it's ready to be specified.

Those are my initial thoughts, anyway. I do see the benefits of the fact that HAMs are CDI beans, but, at a minimum, I think there's complexity here, and some questions that need to be resolved, and little or no time to do so. That's probably my fault, but we are where we are.

Thoughts?

We are where we are indeed. I hope to have answered most questions, and that we can amend the spec today where needed. Especially requiring secure and httponly to default to true would probably be a good thing to add to the spec.

Yes -- thanks for the explanations. I still don't think RememberMe is ready to specify, but I'm more comfortable with the FORM and BASIC annotations. Do you think you could send me a brief write-up of those today?

Thanks,

Will


Thanks for your thorough review!

Kind regards,
Arjan Tijms


 


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


Arjan Tijms
 

Hi,

On Tue, May 16, 2017 at 11:41 AM, Will Hopkins <will.hopkins@...> wrote:
I agree that the existing mechanisms aren't modern, and that there may be use cases where developers want or need to modify the process. That said, I think the legitimate use cases are probably few and far between. Existing implementations of FORM and BASIC have been refined over the years, such that they are robust and handle most reasonable requirements.

The entire purpose of the JSR was though to modernise security and make it more easy for users to us. Sure everything in the various Java EE servers have been refined over the years and handle most reasonable requirements, but if we take that as our most important principal, JSR 375 might not even have been needed (which I don't think is the case).

FORM in it's current uhm form is not modern and certainly not easy to use. There's a mismatch in the mental model between how FORM is to be used and how modern applications are programmed.

 
The example you provide above demonstrates the capability, but doesn't demonstrate the need -- in my view, intervening to check username/password length before actually validating the credentials is misguided on separation of duties grounds -- only the identity store can authoritatively say whether the credentials are valid or not -- and is potentially insecure. Best practice when validating credentials is to return "login failed" for all failure cases, regardless of the cause.

I do agree about not giving the user too much information, that's definitely true. But the fact that you have to enter anything at all is not the kind of information you need to withhold. The password length and various constraints can already be learned when you sign up for a new account, so it's also not something you need to withhold in many cases (cases of public websites mostly).

Look at what e.g. Oracle.com does when you login; https://login.oracle.com/mysso/signon.jsp

If you don't enter anything it says:

"Please enter your username and password"

But even if you don't like the binding and bean validation, the part where you continue the dialog programmatically and set the single "login failed" message from the backing bean is already very valuable. This too is non-obvious how to do when posting to j_security_check,

 
I have not heard feedback from our customers that they need or want to extend the functionality provided by FORM or BASIC authentication in WebLogic.

When I was working on various projects for various companies this need came up quite often. As said, especially in JSF/CDI applications the existing authentication mechanisms are contrived and arcane. I've seen people either struggling to get it integrated, or even more often, don't use the Servlet mechanisms at all but just use Shiro or roll their own variant.

There was a request for this in the JSF JIRA tracker as well, the issue with the most votes actually. We closed it in JSF because we felt such concern would be better handled by the Security JSR.


 
Also -- is it not possible to reference a CDI bean, or perform validation on j_username/j_password in some other way, from a login form using the existing mechanism?

All the existing ways are not so obvious. Sure, it's possible, but that's not the main point of the JSR, which is not only about making things possible, but about making things easier and more aligned with modern Java EE.

 
My proposal would be specify that the container should use an application-supplied IdentityStore for FORM/BASIC if present, but also that the container is permitted to override an application-provided IdentityStore with one of its own. i spent some time reading the CDI spec, and it appears to me that this would be possible by observing events during bean discovery and replacing the application's bean with a container bean when the appropriate event is fired -- I'm still not sure which event is the most appropriate one, though -- I'd be interested in your thoughts, as you clearly know CDI better than I.

Yes, the latter should indeed be possible via CDI. I would say the container is allowed to override the IdentityStoreHandler even, as that one is the true entry point to the identity stores.

By overriding the handler it would make sure that only the container's version is used of everything.

Additionally, the container could also be allowed to just add one or more identity stores, as the default handler is capable of working with multiple ones. That way it would be relatively easy to have the container provided store be at the highest priority with the app provided one as the fallback, or the other way around.

 
Agreed, and I'm generally a fan of consistency. In this case, the question in my mind is whether consistency alone is a good enough reason to require containers to provide this functionality when it would impose an implementation cost on container vendors and there is no clear functional requirement driving it.

The consistency aspect is already one advantage, while being able to decorate or intercept the mechanism is quite an advantage too. That way you can add a lot of things, from auditing (logging the calls to the mechanism and its response), adding SSO capabilities, and what have you. It basically gives applications (and libraries) more handles to extend Java EE security, where the existing mechanisms don't have any.

And containers using the RI and not wishing to put extra effort in can always use the RI provided ones, which are there to be used as well.


Your concern is valid, but we took this into account earlier. I think we had discussions with Alex and perhaps David about this way in the beginning. That's why it says "as defined by the Servlet spec". A lot of thought went onto that seemingly simple fragment of text.

Good to know. Does he existing RI implementation meet that requirement?

It should be, certainly in spirit, as both were implemented following the Servlet spec to the letter, and well over a year of practical testing didn't reveal any inconsistencies. Of course there's always more tests that can be done, but the intend is it follows that requirement indeed.


 
If a vendor chooses to provide two implementations of FORM/BASIC, that problem will still remain. Mandating functionality to drive testing seems like the tail wagging the dog; a focus on a robust TCK seems like a better approach.

That too, of course. But in practice having extension APIs actually be used instead of just being an extension waiting for a user to implement them, has seem to be incredibly useful.

Like I mentioned, in JSF the default component set uses the UIComponent type itself too. So a number of issues were discovered with it because we ourselves had to use it too.

The problem with the TCK only approach is that once it's final, it's final. So you have to predict all cases in advance. But you often can't predict it when you're not actually using it.


 
I don't know these technologies well enough to have an informed opinion on whether h:outputText is duplicative of c:out, but it does seem that JSF is layered on JSP/JSTL in a way that, in my conception, JSR-375 is not layered on Servlet. Although JSR-375 and Servlet are different specs, they are tightly integrated, rather than one being simply layered on top of the other.

Functionality wise h:outputText and c:out are duplicates in JSP.

In Facelets, JSF re-implemented JSTL, meaning you have the exact same tags and namespaces but with a different implementation. That doesn't just concern c:out but the entire JSTL library.

In JSR 375 some things are layered on Servlet, some things are integrated. As it stands the RI is mostly layered, but there are various options in the spec for vendors choosing more integration.

 
I still feel like RememberMe is not well-defined. If it's really a session management facility, then it's under-specified, it shouldn't be delegating to an IdentityStore, and there's no clear rationale for implementing a new session management capability in addition to what the container already provides. Existing container session management is almost certainly more robust and more secure than RememberMe. I would argue that long-lived sessions are a bad idea (as distinct from long-lived authentication tokens), but existing containers allow for configurable session lifetimes.

Configurable session lifetimes would absolutely not help, as a longer session has many side effects, mostly massively increased memory usage.

The major point is that remember me represents a long-lived authentication token. It's really not a session management facility.

 
If it's really an authentication token service, then, again, it's underspecified. There are certainly use cases for long-lived tokens, but the specifics of the token matter.

That's a detail of the implementation of the remember me identity store. The token has to be sufficiently random and the application should store a hash of it, not the token itself.

But at this point these are not concerns for JSR 375. The token only has to be read back by the application that vended it, there's no requirement for any interoperation. Compare this to e.g. a string based password. The mechanism and store only have to accept an opaque string, but what's in the string is an application / business logic concern, not a spec concern.


 
The best way to think about RememberMe is probably in terms of a generic mechanism for token issuance, and that seems to be the intent of RememberMeIdentityStore. But it's not fully "plumbed" -- since HAMs are supposed to interact only with IdentityStoreHandler, not IdentityStore,

The key insight perhaps is that remember me is an authentication mechanism interceptor. It doesn't work primarily on the identity store level, but on the authentication  mechanism level.

As explained in the previous mail, when a request comes in the interceptor chain first looks at the session, then inspects the request for a token to be present (which is at the authentication mechanism level) and then when it encounters such token it will validate this token against the RememberMeIdentityStore.

So it's quite a fully plumbed and integrated whole, but you need to be aware of it working not only at the identity store level, but at the authentication mechanism level as well. This is also one example of what can be done with interceptors for authentication mechanisms.

 
shouldn't IdentityStoreHandler expose generateLoginToken()?

No, this was considered, but ultimately it was agreed that the RememberMeIdentityStore is a sufficiently different kind of store that we should not burden the handler with its extra complexity.

The remember me identity store is to be used exclusively by the remember me interceptor, and therefor should not even be mixed with the collection of stores that are to be invoked by the authentication mechanisms.

 
Also, the removeLoginToken() method is more consistent with a session model than a token issuance model -- issued tokens, especially long-lived ones, are typically not cached because there's no need to -- they can be cryptographically verified, and they contain all the information needed for user identification and authentication.

They can, but in remember me you often want to revoke a specific token. For instance, at an application level the tokens can be assigned names (library, work, home, ...) or IP addresses can be stored, which gives the application the ability to show users a list of all locations they are currently "logged-in" and the ability to remove that login.

Of course it's not an actual login, but just the acceptance of a specific token that happens to be stored at that location.

 
Lastly, the RememberMe annotation provides very little configurability -- it only supports cookies (not, e.g., HTTP headers, or form fields), and even for cookies allows configuration only for cookie name and lifetime.

Those can be expanded over time, of course. For a 1.0 release cookies should be fine. They are the most commonly used artefact. See e.g. http://stackoverflow.com/a/244907/472792 and https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence#title.2

Annotations, which are the entry point to configurability, are very easily extendable (add attributes to them in a backwards compatible way).

It may be a good idea though to add a general key/value map, so vendors can extend the configuration (of which the most popular ones can be put up for standardisation later). Then again, a second vendor specific annotation is always an option as well, so we as spec would not have to worry about that.

 
RememberMe doesn't seem sufficiently well thought out yet.

It really is; a lot of alternatives were considered and rejected, and we looked a lot at existing implementations both in Java and elsewhere. 

Also, as I mentioned, I tested the RI implementation for well over a year, and my previous website https://zeef.com used an approach quite like this since half of 2013 and later on was updated to use exactly this approach. With 200k pageviews a month and ~5k logins a month over a period of 4 years this must certainly count as something that was extensively tested in practice and tuned over the years.

Additionally, this feature was extensively discussed with JSF EG member and general web expert (SO top user) Bauke Scholtz, so we had input from there too.

 
As noted above, that sounds more like a long-lived authentication token than a session.


Indeed, that's exactly what I mentioned above ;) It is a long-lived authentication token and not a session management facility of any kind.


 
I think a key conceptual difference between what happens in step 2 and what happens in step 3. Step two is the container identifying an authentication token and using it to authenticate the user. The function/behavior of step 3 depends on whether FORM is just an alternative authentication mechanism (because multiple acceptable mechanisms are available), or whether step 3 is really a redirect to a token issuance service. (Not necessarily a literal redirect, but a logical redirect.)


Indeed, step 2 and step 3 are conceptually different. Step 1 and 2, while different have a number of things in common.

In both cases, step 1 and 2 prevent the caller from having to go through an authentication dialog for every request. But they are an hierarchy, for step 1, step 2 seems to be the source authentication mechanism, while for step 2 it seems step 3 is (and here it actually is).

 
I think the answer is that one is a session cookie and the other is not (it's an authentication token).

True

 
If the model is really token issuance, the fact that only cookies are supported seems like a bit limitation.

Not sure if it's really a limitation as such at the moment. Especially for the 1.0 release Alex mentioned to go for the low hanging fruit first, which here are cookies. It's designing the initial version of the spec for the 80% out there. The fact that cookies are used now does not exclude other things to be used at a later stage.
 
Yes -- thanks for the explanations. I still don't think RememberMe is ready to specify, but I'm more comfortable with the FORM and BASIC annotations. Do you think you could send me a brief write-up of those today?

I could for sure. The core specification of them is in the annotation now, but as appeared in this conversation it certainly wouldn't hurt to provide more clarification about this in the spec document.

Kind regards,
Arjan Tijms


 

Thanks,

Will


Thanks for your thorough review!

Kind regards,
Arjan Tijms


 


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



Arjan Tijms
 

Hi,

On Tue, May 16, 2017 at 02:41 am, Will Hopkins wrote:

Do you think you could send me a brief write-up of those today?

 See this PR: https://github.com/javaee-security-spec/security-spec/pull/5


Kind regards,

Arjan Tijms


Will Hopkins
 

Thanks, Arjan, just saw it. I'll have a look.

On 05/16/2017 11:55 AM, Arjan Tijms wrote:

Hi,

On Tue, May 16, 2017 at 02:41 am, Will Hopkins wrote:

Do you think you could send me a brief write-up of those today?

 See this PR: https://github.com/javaee-security-spec/security-spec/pull/5


Kind regards,

Arjan Tijms


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


Will Hopkins
 

Arjan,

On 05/16/2017 08:19 AM, Arjan Tijms wrote:
Hi,

On Tue, May 16, 2017 at 11:41 AM, Will Hopkins <will.hopkins@...> wrote:
I agree that the existing mechanisms aren't modern, and that there may be use cases where developers want or need to modify the process. That said, I think the legitimate use cases are probably few and far between. Existing implementations of FORM and BASIC have been refined over the years, such that they are robust and handle most reasonable requirements.

The entire purpose of the JSR was though to modernise security and make it more easy for users to us. Sure everything in the various Java EE servers have been refined over the years and handle most reasonable requirements, but if we take that as our most important principal, JSR 375 might not even have been needed (which I don't think is the case).

OK, good point.

The example you provide above demonstrates the capability, but doesn't demonstrate the need -- in my view, intervening to check username/password length before actually validating the credentials is misguided on separation of duties grounds -- only the identity store can authoritatively say whether the credentials are valid or not -- and is potentially insecure. Best practice when validating credentials is to return "login failed" for all failure cases, regardless of the cause.

I do agree about not giving the user too much information, that's definitely true. But the fact that you have to enter anything at all is not the kind of information you need to withhold. The password length and various constraints can already be learned when you sign up for a new account, so it's also not something you need to withhold in many cases (cases of public websites mostly).

Look at what e.g. Oracle.com does when you login; https://login.oracle.com/mysso/signon.jsp

If you don't enter anything it says:

"Please enter your username and password"

Yes, but there's a difference between the form complaining because you didn't enter *anything*, and complaining about specific issues with with the values a user *did* enter.

But even if you don't like the binding and bean validation, the part where you continue the dialog programmatically and set the single "login failed" message from the backing bean is already very valuable. This too is non-obvious how to do when posting to j_security_check,

Got it.

I have not heard feedback from our customers that they need or want to extend the functionality provided by FORM or BASIC authentication in WebLogic.

When I was working on various projects for various companies this need came up quite often. As said, especially in JSF/CDI applications the existing authentication mechanisms are contrived and arcane. I've seen people either struggling to get it integrated, or even more often, don't use the Servlet mechanisms at all but just use Shiro or roll their own variant.

There was a request for this in the JSF JIRA tracker as well, the issue with the most votes actually. We closed it in JSF because we felt such concern would be better handled by the Security JSR.

OK.

Also -- is it not possible to reference a CDI bean, or perform validation on j_username/j_password in some other way, from a login form using the existing mechanism?

All the existing ways are not so obvious. Sure, it's possible, but that's not the main point of the JSR, which is not only about making things possible, but about making things easier and more aligned with modern Java EE.

I've been thinking in terms of adding new APIs while not necessarily fixing things that aren't broken, but I understand the POV.

My proposal would be specify that the container should use an application-supplied IdentityStore for FORM/BASIC if present, but also that the container is permitted to override an application-provided IdentityStore with one of its own. i spent some time reading the CDI spec, and it appears to me that this would be possible by observing events during bean discovery and replacing the application's bean with a container bean when the appropriate event is fired -- I'm still not sure which event is the most appropriate one, though -- I'd be interested in your thoughts, as you clearly know CDI better than I.

Yes, the latter should indeed be possible via CDI. I would say the container is allowed to override the IdentityStoreHandler even, as that one is the true entry point to the identity stores.

By overriding the handler it would make sure that only the container's version is used of everything.

Additionally, the container could also be allowed to just add one or more identity stores, as the default handler is capable of working with multiple ones. That way it would be relatively easy to have the container provided store be at the highest priority with the app provided one as the fallback, or the other way around.

OK, yhat seems like a good approach, I'll make sure it's spec'd that way. I don't think I'll spec the idea about requiring the container to use an app-supplied IdentityStore -- you've convinced me about the FORM and BASIC annotations, so that's how the app can leverage an IdentityStore for FORM and BASIC.

How do you feel about specifing that HAMs are only required to be enabled when the app is deployed with <auth-method>AUTHMECH</auth-method>, though, to ensure that containers can continue support legacy apps using the existing code paths, and to ensure deterministic behavior when, for example, two implementations of FORM or BASIC are still present in the container. Containers could still choose to provide just one impl, and to implement all functionality via HAM, and apps could ensure they always got HAM by specifying the AUTHMECH, but legacy behavior got be safely preserved if a container vendor chose.

Agreed, and I'm generally a fan of consistency. In this case, the question in my mind is whether consistency alone is a good enough reason to require containers to provide this functionality when it would impose an implementation cost on container vendors and there is no clear functional requirement driving it.

The consistency aspect is already one advantage, while being able to decorate or intercept the mechanism is quite an advantage too. That way you can add a lot of things, from auditing (logging the calls to the mechanism and its response), adding SSO capabilities, and what have you. It basically gives applications (and libraries) more handles to extend Java EE security, where the existing mechanisms don't have any.

And containers using the RI and not wishing to put extra effort in can always use the RI provided ones, which are there to be used as well.

Yep. I see the value. I do think this will add significant additional implementation work for containers, though.

The problem with the TCK only approach is that once it's final, it's final. So you have to predict all cases in advance. But you often can't predict it when you're not actually using it.

True. Hopefully, if the spec is well written and faithfully translated into test cases we can keep issues to a minimum.

I still feel like RememberMe is not well-defined. If it's really a session management facility, then it's under-specified, it shouldn't be delegating to an IdentityStore, and there's no clear rationale for implementing a new session management capability in addition to what the container already provides. Existing container session management is almost certainly more robust and more secure than RememberMe. I would argue that long-lived sessions are a bad idea (as distinct from long-lived authentication tokens), but existing containers allow for configurable session lifetimes.

So the light-bulb went off a little while ago. I had been thinking in terms of bank-level security, general-purpose architecture for token issuance, integration with container session management,etc. -- then I remembered that my bank won't let me stay logged in longer than 20 minutes, but lots of other sites have little "Remember Me" checkboxes, and I understood the use case. It's really not a distinct architectural function, it's more like a feature added onto authentication, so the current implementation makes sense. Sorry for being so dense about it.

That's a detail of the implementation of the remember me identity store. The token has to be sufficiently random and the application should store a hash of it, not the token itself.

Agree it's an implementation detail, but if what you mean is that the client should store only a hash, that doesn't provide any additional security, because the hash will be as good as the "original" token -- it must be possible to use the hash as the authentication token, because that's all the client will have access to. If it's just an identifier, then any unique, random value of sufficient size will do. Hashing algorithms can provide those, but don't really add much value over a good PRNG. If the token carries data, it will have to be encrypted, and the client will have to retain the actual token, not just a hash of it.

Lastly, the RememberMe annotation provides very little configurability -- it only supports cookies (not, e.g., HTTP headers, or form fields), and even for cookies allows configuration only for cookie name and lifetime.

Those can be expanded over time, of course. For a 1.0 release cookies should be fine. They are the most commonly used artefact. See e.g. http://stackoverflow.com/a/244907/472792 and https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence#title.2

Annotations, which are the entry point to configurability, are very easily extendable (add attributes to them in a backwards compatible way).

OK.

It may be a good idea though to add a general key/value map, so vendors can extend the configuration (of which the most popular ones can be put up for standardisation later). Then again, a second vendor specific annotation is always an option as well, so we as spec would not have to worry about that.

Let's not add anything else new.  ;)

RememberMe doesn't seem sufficiently well thought out yet.

It really is; a lot of alternatives were considered and rejected, and we looked a lot at existing implementations both in Java and elsewhere.

Yep, I just didn't get the use case right away.

I think a key conceptual difference between what happens in step 2 and what happens in step 3. Step two is the container identifying an authentication token and using it to authenticate the user. The function/behavior of step 3 depends on whether FORM is just an alternative authentication mechanism (because multiple acceptable mechanisms are available), or whether step 3 is really a redirect to a token issuance service. (Not necessarily a literal redirect, but a logical redirect.)


Indeed, step 2 and step 3 are conceptually different. Step 1 and 2, while different have a number of things in common.

I guess I see them all as functionally distinct now. The first analogy that comes to mind is the hierarchy of storage for a CPU -- the CPU operates on data in registers; data is loaded into registers from the L2 cache, when there's an L2 cache miss the data is loaded from core memory, and data that's not in core memory is read from disk. The fallback process from HTTP session to RememberMe to credentials-based authentication seems analagous.

Yes -- thanks for the explanations. I still don't think RememberMe is ready to specify, but I'm more comfortable with the FORM and BASIC annotations. Do you think you could send me a brief write-up of those today?

I could for sure. The core specification of them is in the annotation now, but as appeared in this conversation it certainly wouldn't hurt to provide more clarification about this in the spec document.

Thanks, saw your recent pull request. I don't think every aspect has to be fully documented in the spec -- javadoc is fine as a detail-level reference -- but I do think the spec needs to at least mention the existence of every significant feature, and probably provide some high level discussion of the feature's purpose and function.

So, on to the next topic -- there are a couple other interfaces I think need to be moved, removed, and/or tweaked:
  • There was discussion on the list a while back about EmbeddedIdentityStore, and whether it represented a security risk and/or an anti-pattern. Although there was not complete agreement within the EG, there was support for the idea that it's not a good practice, and that we shouldn't encourage it by including it in the API. It has value for some development use cases, but those use cases could be easily satisfied by including it in the RI, and ultimately it's pretty trivial to write an actual IdentityStore implementation that has hard-coded user data and/or reads from a file, keystore, or other embedded repository.
I agree with the concern, and intend to remove it from the spec (i.e., API javadoc).
  • For ServletContext, I intend to:
    • Remove the newly added methods (getAllDeclaredCallerRoles() and hasAccessToXXX())
    • As previously agreed, remove the "response only" signature for authenticate (authenticate(HttpServletResponse, AuthenticationParameters)).
    • Specify that ServletContext is supported only in EJB and Servlet containers, or possibly a *short* list of additional containers (likely the web-based containers) where it's known that the getCallerPrincipal() and isCallerInRole() methods can be implemented by layering on existing container APIs.
  • AuthenticationStatus -- weren't we going to align that with the JASPIC return codes, so that the correspondence would be completely clear even though we weren't re-using the actual type/constants?
  • AuthenticationContext -- this is a bit of a kitchen sink. I guess we can live with that, but we at least need to provide javadoc for all of the getters/setters. As the author, you're best positioned to do so, I think.
  • Would BaseMessageContext be a better name for MessageContextWrapper? The class doesn't actually wrap anything, it simply implements the MessageContext interface. (Both classes could use some javadoc.)
  • I'll probably add some fields to the LdapIdentityStoreDefinition annotation to allow developers to specify a particular search string (LDAP syntax) and map a particular LDAP attribute to the caller principal name.

Thanks,

Will

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


Arjan Tijms
 

Hi Will,

On Tue, May 16, 2017 at 11:26 PM, Will Hopkins <will.hopkins@...> wrote:

OK, yhat seems like a good approach, I'll make sure it's spec'd that way. I don't think I'll spec the idea about requiring the container to use an app-supplied IdentityStore -- you've convinced me about the FORM and BASIC annotations, so that's how the app can leverage an IdentityStore for FORM and BASIC.

How do you feel about specifing that HAMs are only required to be enabled when the app is deployed with <auth-method>AUTHMECH</auth-method>, though, to ensure that containers can continue support legacy apps using the existing code paths, and to ensure deterministic behavior when, for example, two implementations of FORM or BASIC are still present in the container. Containers could still choose to provide just one impl, and to implement all functionality via HAM, and apps could ensure they always got HAM by specifying the AUTHMECH, but legacy behavior got be safely preserved if a container vendor chose.

By itself this would be okay, but there are a few caveats.

First is that the CDI bean representing the HAM is initially enabled via a CDI extension. Despite the best efforts of both the CDI and Servlet EGs, nobody succeeded in finding a solution for the fact that currently CDI extensions are not guaranteed to be able to read web.xml.

So without <auth-method>AUTHMECH</auth-method> we should be prepared for the beans still being around, but just not actually used for authentication (when it comes time to install the JASPIC bridge, web.xml can be read).

Second is that specifically simpler applications are trending to a no-XML/no web.xml solution. Requiring a web.xml only to activate JSR 375 is a bit of a step back then. This caveat could be reduced though by introducing an annotation to set the auth mechanism and/or extending the javax.servlet.ServletContext with an option to set the auth mechanism programmatically.

 
So the light-bulb went off a little while ago. I had been thinking in terms of bank-level security, general-purpose architecture for token issuance, integration with container session management,etc. -- then I remembered that my bank won't let me stay logged in longer than 20 minutes, but lots of other sites have little "Remember Me" checkboxes, and I understood the use case. It's really not a distinct architectural function, it's more like a feature added onto authentication, so the current implementation makes sense. Sorry for being so dense about it.

No worries, I'm happy it's clear now. I've had the light-bulb moment myself on multiple occasions too ;)

 
Let's not add anything else new.  ;)

Okay, sure I agree with that.

 
I guess I see them all as functionally distinct now. The first analogy that comes to mind is the hierarchy of storage for a CPU -- the CPU operates on data in registers; data is loaded into registers from the L2 cache, when there's an L2 cache miss the data is loaded from core memory, and data that's not in core memory is read from disk.

Indeed, that's a totally fitting analogy.

 
So, on to the next topic -- there are a couple other interfaces I think need to be moved, removed, and/or tweaked:
  • There was discussion on the list a while back about EmbeddedIdentityStore, and whether it represented a security risk and/or an anti-pattern. Although there was not complete agreement within the EG, there was support for the idea that it's not a good practice, and that we shouldn't encourage it by including it in the API. It has value for some development use cases, but those use cases could be easily satisfied by including it in the RI, and ultimately it's pretty trivial to write an actual IdentityStore implementation that has hard-coded user data and/or reads from a file, keystore, or other embedded repository.
I agree with the concern, and intend to remove it from the spec (i.e., API javadoc).

Well, as mentioned I don't 100% share the concern, although I do see the issue. The fact is that every other application server out there already provides the equivalent to the embedded identity store, though mostly using some sort of file (property or annotation mostly). But since there indeed was not complete agreement about this in the EG, we probably should give this some more thought.

But since we unfortunately don't have the time for that, I (somewhat reluctantly) agree to move this to the RI then. It's late at my place now, but I'll make the attempt tomorrow then.
 
  • For ServletContext, I intend to:
    • Remove the newly added methods (getAllDeclaredCallerRoles() and hasAccessToXXX())
(p.s. I think this is about SecurityContext and not ServletContext, but that's probably just a typo)
 
I'm not sure what the need is for removing those, specifically the hasAccessTo methods. The latter ones are quite often requested by users. Even so much that over at OmniFaces we implemented those by parsing web.xml. This feature has been received with much enthusiasm by our users and is often used. We introduced it a while back so have experience with it for some time as has the general public and wider community.

It's quite important to have the hasAccessTo() methods for e.g. rendering menus in web applications (omit links users don't have access to), or to render links to protected pages in a different way (e.g. in red or with a lock symbol).

See:


Note that in OmniFaces we don't use JACC. I know there's a concern about JACC since it's not enabled by default in WLS (which as I think I mentioned is actually a spec violation), but for this feature JACC is not required. It's just trivial to implement using JACC, and I used that in the RI. But WLS and Liberty (the other server that doesn't have JACC enabled by default) can use proprietary code there, or even copy the code from OmniFaces if they want. 

Alternatively I could also provide the OmniFaces implementation in the RI for the hasAccessTo() methods.

 
    • As previously agreed, remove the "response only" signature for authenticate (authenticate(HttpServletResponse, AuthenticationParameters)).

Okay, I'll remove that one tomorrow too then.
 
    • Specify that ServletContext is supported only in EJB and Servlet containers, or possibly a *short* list of additional containers (likely the web-based containers) where it's known that the getCallerPrincipal() and isCallerInRole() methods can be implemented by layering on existing container APIs.
Okay, with the note that you probably mean SecurityContext here and not ServletContext.

 
  • AuthenticationStatus -- weren't we going to align that with the JASPIC return codes, so that the correspondence would be completely clear even though we weren't re-using the actual type/constants?

Okay, I'm somewhat more in favour of the current names, but we indeed discussed that, so I'm going to make that change too then.


  • AuthenticationContext -- this is a bit of a kitchen sink. I guess we can live with that, but we at least need to provide javadoc for all of the getters/setters. As the author, you're best positioned to do so, I think.
Which class would that exactly be? There's no AuthenticationContext, but there is a HttpMessageContext. Did you meant that one?
 
  • Would BaseMessageContext be a better name for MessageContextWrapper? The class doesn't actually wrap anything, it simply implements the MessageContext interface. (Both classes could use some javadoc.)

HttpMessageContextWrapper actually does wrapping, see e.g.

public class HttpMessageContextWrapper implements HttpMessageContext {

    private final HttpMessageContext httpMessageContext;
 
    public HttpMessageContextWrapper(HttpMessageContext httpMessageContext) {
        this.httpMessageContext = httpMessageContext;
    }
    
    public HttpMessageContext getWrapped() {
        return httpMessageContext;
    }

    @Override
    public boolean isProtected() {
        return getWrapped().isProtected();
    }

It's modelled directly after the Servlet wrappers, e.g. HttpServletRequestWrapper:

public class HttpServletRequestWrapper extends ServletRequestWrapper implements HttpServletRequest {

    /** 
     * Constructs a request object wrapping the given request.
     * @throws java.lang.IllegalArgumentException if the request is null
     */
    public HttpServletRequestWrapper(HttpServletRequest request) {
        super(request);
    }
    
    private HttpServletRequest _getHttpServletRequest() {
        return (HttpServletRequest) super.getRequest();
    }

    /**
     * The default behavior of this method is to return getAuthType()
     * on the wrapped request object.
     */
    @Override
    public String getAuthType() {
        return this._getHttpServletRequest().getAuthType();
    }

 
  • I'll probably add some fields to the LdapIdentityStoreDefinition annotation to allow developers to specify a particular search string (LDAP syntax) and map a particular LDAP attribute to the caller principal name.

Okay, thanks!

Kind regards,
Arjan Tijms



 

Thanks,

Will

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