Date   

Re: JetBrains' concerns with JSR-375

Arjan Tijms
 

Hi,

Thanks a bunch for providing the comments. Good feedback, but as Will mentioned it's indeed very late in the process.

Let me review the list as requested:

  • Core IdentityStore interface: in the IntelliJ IDEA API we don’t accept commits with interfaces like: there are 2 methods, you could implement the first, the second or both and provide the third method that returns what was really implemented. Are there other alternatives? E.g. splitting into multiple interfaces?

This has indeed been a concern and a personal concern for me as well. For the longest time theIdentityStore interface indeed only had a single method; validate(). 

But then we started with the multi-store epic and it turned out to be quite challenging. The key here is that an identity store is not inherently bound to one of those 2 mentioned methods, with the third one describing what was implemented. That would be awkward indeed.

The point is that an identity store can natively implement both of these methods and can then be configured (externally, by for instance the application developer) to be used for either one or both of these purposes. So the third method does not return what was implemented, it returns where the identity store is to be used for.

The current design evolved from a lot of discussion with multiple proposals being implemented and rejected again. At some point we spend so much time on this that we could not really afford to go on with it. Given more time we perhaps could have arrived at a better solution, but we finally reached consensus about this solution, and it worked, so we stuck with it. I personally was hoping to be able to revise some aspects if there was time left at some point, but that time was never there. Somewhat planned was moving the configuration (priority() and validationTypes()) to an external structure of some kind.

Additionally it must be noted that the IdentityStore interface is a little less developer facing than what it may seem to be. The main consumer of it (the authentication mechanism), uses the IdentityStoreHandler (https://github.com/javaee/security-api/blob/master/src/main/java/javax/security/enterprise/identitystore/IdentityStoreHandler.java), which is an interface that only has a single method.

 
  • It looks strange to have in IdentityStore "Set<String> getCallerGroups(CredentialValidationResult validationResult)” and "Set<String> getCallerGroups()" in CredentialValidationResult. It has been explained, it will work, but implementers have to remember all details, it looks like a place for potential bugs. 
To quickly go over this; the validate() method would normally do authentication and the return of the groups associated with the authenticated user in one, potentially optimised, operation. "Set<String> getCallerGroups(CredentialValidationResult validationResult)” splits the latter part of that operation off to an individual method, for those cases where you only want to retrieve the groups.

This is indeed the duality that's being seen: CredentialValidationResult is the result of the operation that does both authentication and the returning of those groups, which by itself appeared to be very common after studying existing implementations.

Conceptually, it would have been cleaner to have a separate validate() method doing only validation, and then always having to call getCallerGroups() for the groups, but that would have made the very common optimisation of doing both of these things in one operation impossible or at least quite hard (pushing extra complexity to the implementation and thus extra complexity to the TCK and other tests).

Using CredentialValidationResult as parameter of the getCallerGroups call is perhaps another small additional source of confusion. Basically the signature was  "Set<String> getCallerGroups(CallerPrincipal callerPrincipal)”, but there were concerns raised about potentially retrieving groups for callers in different stores with non-unique names (for instance two different callers both with the name "john" existing in a DB store and an LDAP store).

These concerns were countered with it being the application or its configurator's responsibility to make sure names are unique among the stores that are configured, but no consensus was reached over this and hence the extra certainty of passing in the CredentialValidationResult was used.
 

  • What is the rule for naming caller groups? Potential issues we can foresee include duplicates, conflicts, non-related group invocations, etc.  

This version of the specification puts no constraints on the names of caller groups. Like in most existing Java EE proprietary implementations and in fact the Java EE specification regarding the closely related concept of roles, the names are completely free form and it's up to the application code how these are used. For instance, a name can represent a simple well understood real-life group name such as "administrator", or it could be a fine grained business rule like name such as "is_able_to_view_margins".

If there's any ambiguity, then it's up to the deployer and/or whatever application level mechanism can be used to map the group names to application logical local role names. The latter are by definition not conflicting or duplicated within a given single application. We had hoped to standardise this group to role mapping as well, but unfortunately didn't have the resources to also include this in the 1.0 version of the spec.

In the meantime at least the container specific mapping facilities can be used for this, something which is quite commonly available in Java EE implementations. Hopefully this can be standardises in the next revision of the spec.
 

  • Annotations: @LdapIdentityStoreDefinition contains 20+ attributes.  Is it likely some bean will need all these non default attribute values? It could lead to some difficult-to-read code
This concern was not raised before, but I can't say I entirely disagree with this. LDAP though is a notoriously flexible "format", by which I mean that the information can be stored in a very large number of different ways. An alternative could have been to have multiple @LdapIdentityStoreDefinition annotations, each with a specific kind of approach to retrieving the data we need from LDAP. I'm not sure if that would have made things simpler or not.

 
  • “Chapter 2: Authentication mechanism” describes the HttpAuthenticationMechanism interface and "is specified only for use in the Servlet container". Isn't this more an extension of Servlet 3.x specification?
Yes, in a way it certainly is. Like the JASPIC Container Servlet Profile on which it builds, this could potentially have been put in the Servlet specification as well.

However, the way the JCP and specs are currently organised makes it non-trivial to have the kind of inter-spec coordination needed to realise this. Several attempts were made though; the Servlet EG was asked to take ownership of the so-called HttpServletRequest CDI build-in bean (a kind of producer that makes the injection of HttpServletRequest possible). This however was not entirely understood by the Servlet EG, in part because not all members are fully up to date with what CDI exactly entails. With this quite simple CDI artefact being rejected, the chances of the Servlet EG incorporating the larger HttpAuthenticationMechanism, which is heavily dependent on CDI were deemed slim.

Additionally, the mentioned JASPIC Container Servlet Profile, on which the HttpAuthenticationMechanism directly builds, did not make it into the Servlet spec either. At some point the Servlet EG seemed willing to adopt it (in fact, the Servlet spec itself already encourages this, but does not demand it), but ultimately this did not make it in.

That all said, being an extension of the Servlet spec or building on it, is not unprecedented. JSF for instance builds on Servlet and is its own spec as well.
 

  • IdentityStore priority: “Lower numbers represent higher priority”. But “getPriority()” methods in the JDK (Thread, AWT) have “higher numbers for higher priority”.  The IntelliJ API, Spring, Hibernate and other frameworks use the same concept.  Is “lower numbers for higher priority” is used in OS threads? Or what's the reasoning behind this decision?

The reasoning behind it is more about ordering. Lower priority stores are consulted first, higher priority later. This is basically how the Interceptor Spec works as well; lower priority interceptors are put first in the chain, higher priority ones later, and then the chain is executed from the beginning. An interceptor has the ability to not continue the chain, so in a certain way an earlier (lower level priority) interceptor is more powerful than a later level. 

The default traversal algorithm for stores in JSR 375 uses a "first one to validate successfully wins" strategy, but this is not necessarily the inherent way that the identity store priority has to be seen. The traversal algorithm (handler, really) is replaceable, and could use a strategy such that later (higher priority) stores essentially "win".

See also the documentation on the @Priority annotation, which is what this decision was directly based on:

/**
 * The Priority annotation can be applied to classes to indicate
 * in what order the classes should be used.  The effect of using
 * the Priority annotation in any particular instance is defined
 * by other specifications that define the use of a specific class.
 * <p>
 * For example, the Interceptors specification defines the use of
 * priorities on interceptors to control the order in which
 * interceptors are called.
 * <p>
 * Priority values should generally be non-negative, with negative values
 * reserved for special meanings such as "undefined" or "not specified".
 * A specification that defines use of the Priority annotation may define
 * the range of allowed priorities and any priority values with special
 * meaning.
 *
 * @since Common Annotations 1.2
 */
@Target({TYPE})
@Retention(RUNTIME)
@Documented
public @interface Priority

Hope this clears it up at least a little. Given the point we are in the process I'm not sure how much if any action we can still take, other than perhaps some clarification in the spec text and/or javadoc.

Kind regards,
Arjan Tijms


 
If you have further questions about the feedback, please feel free to contact Sergey directly, or myself. And we'll be more than happy to either receive email clarification on the questions, or links to relevant discussions in the mailing list archives - we acknowledge we're late to the process and that some (or all) of these points may have been discussed previously.  Of course, any confusion we have may also be shared by end users!

Thanks once again for reaching out and trying to understand our issues.

Trisha

On Tue, Jul 25, 2017 at 7:15 PM Will Hopkins <will.hopkins@...> wrote:
Great, thanks for letting me know. We actually have a couple more tweaks planned for an updated PFD that should be available shortly, I'll forward that along when it's ready.

Let us know if anything further comes up.


Will


On 07/25/2017 06:33 AM, Trisha Gee wrote:
Those who had concerns with the spec are much happier with the updated version.  I *still* haven't had more detailed feedback from those who had concerns (sorry), I will give them a poke.

On 23 July 2017 at 23:08, Will Hopkins <will.hopkins@...> wrote:
Hi Trisha,

Just wanted to touch base and see if there was any further feedback ...

Regards,

Will


On 07/11/2017 01:30 PM, Will Hopkins wrote:
Thanks, Trisha.

On 07/11/2017 01:12 PM, Trisha Gee wrote:

Thank you so much for reaching out and for providing the updated spec. I appreciate you have a difficult job balancing delivering something in a reasonable time frame that also provides a good set of standards for the future, and I also appreciate that our feedback is rather late in the process (but we are new to the EC!).

I will pass on the updated spec to our (JetBrains) EC working group, specifically to those who had concerns around this JSR, and will also be chasing them again for the more detailed feedback I have promised you. I'll most likely be putting you directly in touch with those who had specific concerns so I'm not getting in the way as a middle man.

Trisha


On Tue, 11 Jul 2017, 19:02 Will Hopkins, <will.hopkins@...> wrote:
Hi Trisha,

I'm the spec lead for JSR-375, and wanted to reach out to you about the concerns expressed with your "no" vote on the JSR-375 Public Review ballot.

I'm obviously interested to hear the detailed feedback you mentioned, but in advance of that I want to provide you with an updated version of the spec (attached), and the accompanying javadoc (https://www.dropbox.com/s/1bq7n8sz25eyfcb/jsr375-javadoc-1.0-b07-pfd.zip?dl=0), which we have just submitted as a Proposed Final Draft. I think it should address at least some of your concerns. In particular, it provides a solution for the issue of static attribute values for the LDAP identity store and other annotations (Issue #76) -- all annotation attributes can now be specified as EL expressions.

I'd also like to address the concern about lack of support for OpenID (I assume this means OpenID Connect), and potentially other technologies. We made an explicit decision not to include OpenID Connect, because we didn't think it would fit in the time we had available, but we do agree that OpenID Connect, and OAuth2, are important technologies. The idea was to provide a base on which features like OpenID Connect could be built, and we do think that JSR-375 is useful, both on its own merits, and as an enabling technology for future additions.

We look forward to your detailed feedback.

Best Regards,

Will Hopkins
Spec Lead
JSR-375

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



Re: IdentityStore/AuthenticationMechanism properties validation

Guillermo González de Agüero
 

Just a ping here as the FAB is scheduled for this Sunday. Does anyone have an opinion here?

Both implementation and spec changes should be minimal and I could work on them myself if you agree on this.


Regards,

Guillermo González de Agüero

El mié., 26 jul. 2017 a las 7:56, Guillermo González de Agüero (<z06.guillermo@...>) escribió:
Hi,

We already talked about validation of attributes ([1] and [2]) and canceling deployment in case of invalid ones. At that time we came to the conclusion that it was too difficult to do and that it was better not to standarize that behavior at this time.

But then with [3] I had another idea I'd like to propose to the EG. The other time we talked about the runtime validating properties for the stores. What I propose now is that identity stores themselves validate their parameters. I've thought of two posible ways:
- Add a "init() throws Exception" method to IdentityStore/HttpAuthenticationMechanism.
- Specify that an exception thrown from a @PostConstruct annotated method on an IdentityStore or HttpAuthenticationMechanism makes deployment fail. Only unchecked exceptions can be thrown on @PostConstruct methods.

This behavior is aligned with what Servlets/Singleton EJBs/eager ApplicationScoped CDI beans do. The only required change is that identity stores and authentication mechanism would need to be created at deployment time, to be able to cancel deployment if needed.

I'd go for the @PostConstruct alternative as it's the less intrusive and more "CDIish" way to do it. Changes to the spec and implementation are minimal, while providing users the ability to validate their own artifacts. This would also help [3] case reducing runtime exceptions to just unexpected ones.

What do you think?


Regards,

Guillermo González de Agüero:

[1] https://javaee.groups.io/g/javaee-security-spec/message/324
[2] https://github.com/javaee/security-soteria/issues/104
[3] https://github.com/javaee/security-soteria/pull/124


Re: JCON - Call for Papers

Will Hopkins
 

Great news!

On 07/28/2017 09:37 AM, Werner Keil wrote:
Hi,

Glad to share, the JCon Java conference in Düsseldorf at the end of October accepted my proposal for Java EE Security related to JSR 375.

Werner


---------- Forwarded message ----------
From: Sebastian Dippold
Date: 2017-07-28 14:52 GMT+02:00
Subject: JCON - Call for Papers
To: "werner"


Hallo Werner,

herzlichen Glückwunsch, Ihr Vortrag

Java Enterprise Security

wurde angenommen.
Der JCON 2017 Sessionplan mit insgesamt 70 Speakern und über 85 Sessions, ist jetzt online. Das Anzeigen der Speaker-Profile sowie verbesserte Suchfunktionen kommen in den nächsten Tagen noch dazu.

Was wir von Ihnen noch brauchen
Bitte überprüfen Sie die Daten zu Ihrem Vortrag und informieren Sie uns, falls wir einen Fehler gemacht haben und wenn Sie noch etwas ändern oder ergänzen möchten.

Bitte senden Sie uns noch folgende Informationen, die wir beim Call-for-Papers Formular noch nicht abgefragt haben:

  • Ihr Job-Titel
  • Foto - Möglichst gute Qualität (300dpi), auch für den Druck geeignet, bitte mit Ihrem Namen im Dateinamen
  • Kontaktdaten - die Sie zu Ihrem Speaker-Profil angeben möchten, u.a. Twitter, LinkedIn, XING
  • Blog-URL - die Sie angeben möchten
  • Firmen-Profil - Um unsere Speaker noch besser zu promoten, bieten wir Ihnen an, dass Sie Ihr Speaker-Profil mit einem Firmen-Profil erweitern können, max. 800 Zeichen.

Änderungen am Session-Plan
Wichtig: Aus organisatorischen Gründen kann es noch zu Änderungen kommen, was die Reihenfolge der Sessions (am selben Tag) oder die Raumaufteilung betrifft. Da uns Ihre Planungssicherheit am Herzen liegt, werden Sessions nur in Ausnahmefällen und in Absprache mit dem betroffenen Speaker nachträglich auf einen anderen Tag verlegt.

Ihr Vortrag im JAVAPRO Magazin zur JCON 2017
Wenn Sie den Ihren Vortrag bis zum 14. August 2017 als Artikel bei uns einreichen, wird dieser im nächsten JAVAPRO Magazin abgedruckt, das jeder JCON 2017 Teilnehmer erhält. Als Autor und JCON-Top-Speaker gekennzeichnet, bekommen Sie eine prominente Sichtbarkeit, eine zusätzliche Bewerbung Ihres Vortrags und die JCON Teilnehmer können den Inhalt Ihres Vortrags jederzeit nochmals nachlesen. Auf Grund des Titelthemas Java 9 haben Core Java und Java EE Themen besonders gute Chancen. Sind Sie dabei? Dann senden Sie bitte Ihren Vorschlag an Sebastian Dippold, sdi@....

Infos zum Artikel:

  • Umfang: möglich sind 1 bis 5 Heft-Seiten, entspricht ca. 8.000 - 30.000 Zeichen, Sie entscheiden selbst über den Umfang Ihres Artikels
  • Abgabetermin: 14. August 2017

Aufzeichnungen & JCON STUDIO
Sessions werden aufgezeichnet und nach der Konferenz über unsere Webseiten www.jcon.one und www.java-pro.de veröffentlicht. In unserem JCON STUDIO produzieren wir vor Ort Interviews und Webcasts, die wir bereits während der Konferenz veröffentlichen. Als Speaker können Sie sich dazu vorab anmelden. Wir werden Sie dazu gesondert informieren. 

Ihr Konferenzpass
Als Speaker erhalten Sie einen kostenlosen „Speakerpass“, der Sie zum Besuch aller drei Konferenztage bemächtigt. Der Speakerpass wird Ihnen rechtzeitig vor Beginn der JCON per Post zugestellt. 

Speaker & Exhibitor Welcome Party
Als Einstimmung zur JCON laden wir Sie recht herzlich zur Speaker & Exhibitor Welcome Party ein, die am Montag, 23. Oktober 2017, ab 19:00 Uhr beginnt. Hier können Sie das JAVAPRO und JCON Team, andere JCON Speaker und Aussteller kennen lernen, networken oder einfach nur relaxen und Spaß haben. Den genauen Veranstaltungsort teilen wir Ihnen in Kürze mit.

Bewerben Sie Ihren Vortrag
Alle Sessions werden von uns über unsere noch jungen Social-Media-Channels beworben. Wir freuen uns deshalb sehr, wenn Sie Ihre JCON 2017 Session zusätzlich über Ihr eigenes Netzwerk bewerben.

 

Wir freuen uns sehr, dass Sie als Speaker mit dabei, auf eine tolle JCON 2017 zusammen mit Ihnen und wünschen Ihnen eine gute Anreise. 
Über Änderungen und die neuesten Infos halten wir Sie per E-Mail auf dem Laufenden. Für Fragen, Wünsche und Anregungen stehen wir Ihnen jederzeit gerne zur Verfügung.

  

Viele Grüße,

 

Sebastian Dippold

Chefredakteur

+49 (0) 61 96 – 20 48 01 – 0 

 

Javapro-Logo

Twitter_bird_logo_2012twitter.com/JAVAPROmagazin

1024px-F_iconfacebook.com/JavaproMag

 

http://java-pro.de/ 

Redaktion JAVAPRO | IT Press & Media GmbH | Mergenthalerallee 73-75 | 65760 Eschborn
E-Mail: info[at]java-pro.de

Registergericht: AG Frankfurt am Main | Geschäftsführer: Sebastian Dippold | Sitz der Gesellschaft: 65760 Eschborn | Copyright © 2017 IT Press & Media GmbH

Alle Rechte vorbehalten | Java™ ist ein eingetragenes Warenzeichen der Oracle Coorperation.

 

Die JAVAPRO ist das deutschlandweit erste kostenlose Magazin für Java, es erscheint alle drei  Monate. Als kostenloses Magazin ist die JAVAPRO nicht im Zeitschriftenhandel erhältlich, sondern kann ausschließlich unter java-pro.de bestellt werden. Die Lieferung erfolgt frei Haus und umfasst alle Ausgaben eines Jahres.

Herausgeber der JAVAPRO ist die IT Press & Media GmbH.

 

IT Press & Media GmbH i.G. - Mergenthalerallee 73-75, 65760 Eschborn - Registergericht: AG Frankfurt am Main, Geschäftsführer: Sebastian Dippold, Sitz der Gesellschaft: 65760 Eschborn


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


Re: JetBrains' concerns with JSR-375

Will Hopkins
 

EG:

Forwarding this mail from JetBrains, with their permission. They are happier with the PFD spec, but did provide a list of concerns they have. They understand that it will be difficult to make any non-trivial changes to the spec at this point, but I think it's worth us reviewing the list to see if there's anything we want to do differently, and to respond to the concerns.

Will


-------- Forwarded Message --------
Subject: Re: JetBrains' concerns with JSR-375
Date: Thu, 27 Jul 2017 14:07:32 -0400
From: Will Hopkins <will.hopkins@...>
To: Trisha Gee <trisha.gee@...>
CC: Jeff Tancill <jeff.tancill@...>, Sergey Vasiliev <sergey.vasiliev@...>


Thanks Trisha (and Sergey).

This is very helpful feeback. Indeed, many (not all) of these questions have been discussed in the EG.

At this point, I think it makes sense to include the entire EG in the conversation. Can I forward this to the EG mailing list? Alternatively, if you (or Sergey) would like to send your concerns directly to the list, that might facilitate a more direct conversation.

Please note that, while we value the feedback, and may still be able to make small changes to the language of the spec, we are now just days away from our date to submit FAB materials. We would need a very compelling reason to make any non-trivial change to the API, and doing so would almost certainly cause us to miss our dates -- which would have a follow-on effect for the entire EE 8 release.

Regards,

Will

On 07/27/2017 12:12 PM, Trisha Gee wrote:
Hi Will,

I'd like to introduce you to Sergey Vasiliev (CC'd) who's a member of the JetBrains JCP working group.  Sergey has the most concerns around JSR-375, I'm going to list the main ones here, but Sergey is probably the best person to ask if you need further clarification.

The spec for JSR-375 is quite good, it will work, the Java EE community needs it, but there are a number of areas that seem like possible places for bugs or errors which made us uncomfortable with a "yes" vote.
  • Core IdentityStore interface: in the IntelliJ IDEA API we don’t accept commits with interfaces like: there are 2 methods, you could implement the first, the second or both and provide the third method that returns what was really implemented. Are there other alternatives? E.g. splitting into multiple interfaces?
  • It looks strange to have in IdentityStore "Set<String> getCallerGroups(CredentialValidationResult validationResult)” and "Set<String> getCallerGroups()" in CredentialValidationResult. It has been explained, it will work, but implementers have to remember all details, it looks like a place for potential bugs. 
  • What is the rule for naming caller groups? Potential issues we can foresee include duplicates, conflicts, non-related group invocations, etc.  
  • Annotations: @LdapIdentityStoreDefinition contains 20+ attributes.  Is it likely some bean will need all these non default attribute values? It could lead to some difficult-to-read code
  • “Chapter 2: Authentication mechanism” describes the HttpAuthenticationMechanism interface and "is specified only for use in the Servlet container". Isn't this more an extension of Servlet 3.x specification?
  • IdentityStore priority: “Lower numbers represent higher priority”. But “getPriority()” methods in the JDK (Thread, AWT) have “higher numbers for higher priority”.  The IntelliJ API, Spring, Hibernate and other frameworks use the same concept.  Is “lower numbers for higher priority” is used in OS threads? Or what's the reasoning behind this decision?
If you have further questions about the feedback, please feel free to contact Sergey directly, or myself. And we'll be more than happy to either receive email clarification on the questions, or links to relevant discussions in the mailing list archives - we acknowledge we're late to the process and that some (or all) of these points may have been discussed previously.  Of course, any confusion we have may also be shared by end users!

Thanks once again for reaching out and trying to understand our issues.

Trisha

On Tue, Jul 25, 2017 at 7:15 PM Will Hopkins <will.hopkins@...> wrote:
Great, thanks for letting me know. We actually have a couple more tweaks planned for an updated PFD that should be available shortly, I'll forward that along when it's ready.

Let us know if anything further comes up.


Will


On 07/25/2017 06:33 AM, Trisha Gee wrote:
Those who had concerns with the spec are much happier with the updated version.  I *still* haven't had more detailed feedback from those who had concerns (sorry), I will give them a poke.

On 23 July 2017 at 23:08, Will Hopkins <will.hopkins@...> wrote:
Hi Trisha,

Just wanted to touch base and see if there was any further feedback ...

Regards,

Will


On 07/11/2017 01:30 PM, Will Hopkins wrote:
Thanks, Trisha.

On 07/11/2017 01:12 PM, Trisha Gee wrote:

Thank you so much for reaching out and for providing the updated spec. I appreciate you have a difficult job balancing delivering something in a reasonable time frame that also provides a good set of standards for the future, and I also appreciate that our feedback is rather late in the process (but we are new to the EC!).

I will pass on the updated spec to our (JetBrains) EC working group, specifically to those who had concerns around this JSR, and will also be chasing them again for the more detailed feedback I have promised you. I'll most likely be putting you directly in touch with those who had specific concerns so I'm not getting in the way as a middle man.

Trisha


On Tue, 11 Jul 2017, 19:02 Will Hopkins, <will.hopkins@...> wrote:
Hi Trisha,

I'm the spec lead for JSR-375, and wanted to reach out to you about the concerns expressed with your "no" vote on the JSR-375 Public Review ballot.

I'm obviously interested to hear the detailed feedback you mentioned, but in advance of that I want to provide you with an updated version of the spec (attached), and the accompanying javadoc (https://www.dropbox.com/s/1bq7n8sz25eyfcb/jsr375-javadoc-1.0-b07-pfd.zip?dl=0), which we have just submitted as a Proposed Final Draft. I think it should address at least some of your concerns. In particular, it provides a solution for the issue of static attribute values for the LDAP identity store and other annotations (Issue #76) -- all annotation attributes can now be specified as EL expressions.

I'd also like to address the concern about lack of support for OpenID (I assume this means OpenID Connect), and potentially other technologies. We made an explicit decision not to include OpenID Connect, because we didn't think it would fit in the time we had available, but we do agree that OpenID Connect, and OAuth2, are important technologies. The idea was to provide a base on which features like OpenID Connect could be built, and we do think that JSR-375 is useful, both on its own merits, and as an enabling technology for future additions.

We look forward to your detailed feedback.

Best Regards,

Will Hopkins
Spec Lead
JSR-375

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


JCON - Call for Papers

Werner Keil
 

Hi,

Glad to share, the JCon Java conference in Düsseldorf at the end of October accepted my proposal for Java EE Security related to JSR 375.

Werner


---------- Forwarded message ----------
From: Sebastian Dippold
Date: 2017-07-28 14:52 GMT+02:00
Subject: JCON - Call for Papers
To: "werner"


Hallo Werner,

herzlichen Glückwunsch, Ihr Vortrag

Java Enterprise Security

wurde angenommen.
Der JCON 2017 Sessionplan mit insgesamt 70 Speakern und über 85 Sessions, ist jetzt online. Das Anzeigen der Speaker-Profile sowie verbesserte Suchfunktionen kommen in den nächsten Tagen noch dazu.

Was wir von Ihnen noch brauchen
Bitte überprüfen Sie die Daten zu Ihrem Vortrag und informieren Sie uns, falls wir einen Fehler gemacht haben und wenn Sie noch etwas ändern oder ergänzen möchten.

Bitte senden Sie uns noch folgende Informationen, die wir beim Call-for-Papers Formular noch nicht abgefragt haben:

  • Ihr Job-Titel
  • Foto - Möglichst gute Qualität (300dpi), auch für den Druck geeignet, bitte mit Ihrem Namen im Dateinamen
  • Kontaktdaten - die Sie zu Ihrem Speaker-Profil angeben möchten, u.a. Twitter, LinkedIn, XING
  • Blog-URL - die Sie angeben möchten
  • Firmen-Profil - Um unsere Speaker noch besser zu promoten, bieten wir Ihnen an, dass Sie Ihr Speaker-Profil mit einem Firmen-Profil erweitern können, max. 800 Zeichen.

Änderungen am Session-Plan
Wichtig: Aus organisatorischen Gründen kann es noch zu Änderungen kommen, was die Reihenfolge der Sessions (am selben Tag) oder die Raumaufteilung betrifft. Da uns Ihre Planungssicherheit am Herzen liegt, werden Sessions nur in Ausnahmefällen und in Absprache mit dem betroffenen Speaker nachträglich auf einen anderen Tag verlegt.

Ihr Vortrag im JAVAPRO Magazin zur JCON 2017
Wenn Sie den Ihren Vortrag bis zum 14. August 2017 als Artikel bei uns einreichen, wird dieser im nächsten JAVAPRO Magazin abgedruckt, das jeder JCON 2017 Teilnehmer erhält. Als Autor und JCON-Top-Speaker gekennzeichnet, bekommen Sie eine prominente Sichtbarkeit, eine zusätzliche Bewerbung Ihres Vortrags und die JCON Teilnehmer können den Inhalt Ihres Vortrags jederzeit nochmals nachlesen. Auf Grund des Titelthemas Java 9 haben Core Java und Java EE Themen besonders gute Chancen. Sind Sie dabei? Dann senden Sie bitte Ihren Vorschlag an Sebastian Dippold, sdi@....

Infos zum Artikel:

  • Umfang: möglich sind 1 bis 5 Heft-Seiten, entspricht ca. 8.000 - 30.000 Zeichen, Sie entscheiden selbst über den Umfang Ihres Artikels
  • Abgabetermin: 14. August 2017

Aufzeichnungen & JCON STUDIO
Sessions werden aufgezeichnet und nach der Konferenz über unsere Webseiten www.jcon.one und www.java-pro.de veröffentlicht. In unserem JCON STUDIO produzieren wir vor Ort Interviews und Webcasts, die wir bereits während der Konferenz veröffentlichen. Als Speaker können Sie sich dazu vorab anmelden. Wir werden Sie dazu gesondert informieren. 

Ihr Konferenzpass
Als Speaker erhalten Sie einen kostenlosen „Speakerpass“, der Sie zum Besuch aller drei Konferenztage bemächtigt. Der Speakerpass wird Ihnen rechtzeitig vor Beginn der JCON per Post zugestellt. 

Speaker & Exhibitor Welcome Party
Als Einstimmung zur JCON laden wir Sie recht herzlich zur Speaker & Exhibitor Welcome Party ein, die am Montag, 23. Oktober 2017, ab 19:00 Uhr beginnt. Hier können Sie das JAVAPRO und JCON Team, andere JCON Speaker und Aussteller kennen lernen, networken oder einfach nur relaxen und Spaß haben. Den genauen Veranstaltungsort teilen wir Ihnen in Kürze mit.

Bewerben Sie Ihren Vortrag
Alle Sessions werden von uns über unsere noch jungen Social-Media-Channels beworben. Wir freuen uns deshalb sehr, wenn Sie Ihre JCON 2017 Session zusätzlich über Ihr eigenes Netzwerk bewerben.

 

Wir freuen uns sehr, dass Sie als Speaker mit dabei, auf eine tolle JCON 2017 zusammen mit Ihnen und wünschen Ihnen eine gute Anreise. 
Über Änderungen und die neuesten Infos halten wir Sie per E-Mail auf dem Laufenden. Für Fragen, Wünsche und Anregungen stehen wir Ihnen jederzeit gerne zur Verfügung.

  

Viele Grüße,

 

Sebastian Dippold

Chefredakteur

+49 (0) 61 96 – 20 48 01 – 0 

 

Javapro-Logo

Twitter_bird_logo_2012twitter.com/JAVAPROmagazin

1024px-F_iconfacebook.com/JavaproMag

 

http://java-pro.de/ 

Redaktion JAVAPRO | IT Press & Media GmbH | Mergenthalerallee 73-75 | 65760 Eschborn
E-Mail: info[at]java-pro.de

Registergericht: AG Frankfurt am Main | Geschäftsführer: Sebastian Dippold | Sitz der Gesellschaft: 65760 Eschborn | Copyright © 2017 IT Press & Media GmbH

Alle Rechte vorbehalten | Java™ ist ein eingetragenes Warenzeichen der Oracle Coorperation.

 

Die JAVAPRO ist das deutschlandweit erste kostenlose Magazin für Java, es erscheint alle drei  Monate. Als kostenloses Magazin ist die JAVAPRO nicht im Zeitschriftenhandel erhältlich, sondern kann ausschließlich unter java-pro.de bestellt werden. Die Lieferung erfolgt frei Haus und umfasst alle Ausgaben eines Jahres.

Herausgeber der JAVAPRO ist die IT Press & Media GmbH.

 

IT Press & Media GmbH i.G. - Mergenthalerallee 73-75, 65760 Eschborn - Registergericht: AG Frankfurt am Main, Geschäftsführer: Sebastian Dippold, Sitz der Gesellschaft: 65760 Eschborn


Identify 2017

Werner Keil
 

Hi,

Although this looks like a vendor-specific event, Ping Identity seems relatively big in the Security and Identiy market, so maybe a few of us (especially those at Oracle if they're allowed to go) could find this event interesting. There are 3 in San Francisco, New York and London. The ~300€ price tag looks reasonable if you compare it to e.g. JavaOne. 
Maybe an opportunity to raise awareness about JSR 375.

I have not used it so far myself, but Ping Identity does offer Java Integration: https://documentation.pingidentity.com/display/LP/Java+Integration+Kit+2.4.2

Kind Regards,
Werner


 
Facebook   Twitter   LinkedIn   YouTube
PRODUCTS   SOLUTIONS   CUSTOMERS    RESOURCES   ABOUT
Ping Identity

Hello Werner

It’s time to IDENTIFY yourself. We invite you to the event that’s designed for the Ping community, by the Ping community. IDENTIFY 2017 is gathering in London on October 25, and we’re focused on enabling security, trust and seamless customer engagement. Here’s why it’s the event you won’t want to miss:

  • Hear real stories from real customers on how they’re modernising legacy IAM, driving customer engagement, enhancing security and agility and more.

  • Take a peek into the latest capabilities of the Ping Identity Platform as well as the roadmap for what the future holds.

  • Get hands-on experience in our new workshops to learn how you can make the most of an investment with Ping.

You’ll gain valuable insights into how Ping customers—some of the world’s largest organisations—are improving enterprise security, increasing employee and partner productivity and providing seamless customer engagement with our Identity Defined Security solutions.

REGISTER NOW

We hope to see you there!

The Ping Identity Team

Ping Identity, 283-288 High Holborn, London, WC1V 7HP | +44.207.190.9105
©2003-2017 Ping Identity Corporation | Privacy
 

Unsubscribe

 


Re: Pbkdf2PasswordHashImpl generate() creates sometimes invalid result

Rudy De Busscher
 


yes indeed, somehow I mixed the output of the generate() method with the encoded password I created for the test cases.

I used the  com.sun.org.apache.xml.internal.security.utils.Base64 class instead of the java.util one;

I updated the pull request accordingly.

Rudy

On 27 July 2017 at 19:38, Will Hopkins <will.hopkins@...> wrote:
Just did a test, not seeing any line breaks after encoding a 1024-byte buffer of random data. The line breaks must be coming from somewhere else (not the Pbkdf2PasswordHash, AFAICT).

On 07/27/2017 01:33 PM, Will Hopkins wrote:
This should not be happening. I'm using the "Basic" encoder (Base64.getEncoder()), which, per the Base64 Javadoc, should not be inserting any line feed/line separator characters.

https://docs.oracle.com/javase/8/docs/api/java/util/Base64.html

Will

On 07/27/2017 06:31 AM, Rudy De Busscher wrote:
During the tests I was writing for Pbkdf2PasswordHashImpl, I saw that Pbkdf2PasswordHashImpl#generate() generates a result with line breaks in it.

PBKDF2WithHmacSHA512:1024:QRyYndGzgjmZ7DT51fQ4orSJp5b1IkEaY7qFp9o0Q8ZW4GuR7A7sOQN80Dtrqh1stXjK/VSj5+TY\nZClDbdM/wQ==:VNDmODrwU/geTRbtYaQXOrraPh1XP38qM1rRJtLts0OVLjpCq8Q5OYMdxR5whK7JgJpWQqMh1zIh\nYoTLatrXWA==

(the above example is when using a longer salt and longer key size, both 64)

This is due to the fact that the Base64 algorithm adds line breaks after every 76 character.

But these line breaks makes the Base64 invalid when we call the verify() method with this kind of values.

My proposal is to remove them (the line breaks)  during generation of the hash (generate() method) and also clean them out before base64 decoding (decode() method)

Rudy


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

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



Re: Pbkdf2PasswordHashImpl generate() creates sometimes invalid result

Will Hopkins
 

Just did a test, not seeing any line breaks after encoding a 1024-byte buffer of random data. The line breaks must be coming from somewhere else (not the Pbkdf2PasswordHash, AFAICT).

On 07/27/2017 01:33 PM, Will Hopkins wrote:
This should not be happening. I'm using the "Basic" encoder (Base64.getEncoder()), which, per the Base64 Javadoc, should not be inserting any line feed/line separator characters.

https://docs.oracle.com/javase/8/docs/api/java/util/Base64.html

Will

On 07/27/2017 06:31 AM, Rudy De Busscher wrote:
During the tests I was writing for Pbkdf2PasswordHashImpl, I saw that Pbkdf2PasswordHashImpl#generate() generates a result with line breaks in it.

PBKDF2WithHmacSHA512:1024:QRyYndGzgjmZ7DT51fQ4orSJp5b1IkEaY7qFp9o0Q8ZW4GuR7A7sOQN80Dtrqh1stXjK/VSj5+TY\nZClDbdM/wQ==:VNDmODrwU/geTRbtYaQXOrraPh1XP38qM1rRJtLts0OVLjpCq8Q5OYMdxR5whK7JgJpWQqMh1zIh\nYoTLatrXWA==

(the above example is when using a longer salt and longer key size, both 64)

This is due to the fact that the Base64 algorithm adds line breaks after every 76 character.

But these line breaks makes the Base64 invalid when we call the verify() method with this kind of values.

My proposal is to remove them (the line breaks)  during generation of the hash (generate() method) and also clean them out before base64 decoding (decode() method)

Rudy


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

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


Re: Pbkdf2PasswordHashImpl generate() creates sometimes invalid result

Will Hopkins
 

This should not be happening. I'm using the "Basic" encoder (Base64.getEncoder()), which, per the Base64 Javadoc, should not be inserting any line feed/line separator characters.

https://docs.oracle.com/javase/8/docs/api/java/util/Base64.html

Will

On 07/27/2017 06:31 AM, Rudy De Busscher wrote:
During the tests I was writing for Pbkdf2PasswordHashImpl, I saw that Pbkdf2PasswordHashImpl#generate() generates a result with line breaks in it.

PBKDF2WithHmacSHA512:1024:QRyYndGzgjmZ7DT51fQ4orSJp5b1IkEaY7qFp9o0Q8ZW4GuR7A7sOQN80Dtrqh1stXjK/VSj5+TY\nZClDbdM/wQ==:VNDmODrwU/geTRbtYaQXOrraPh1XP38qM1rRJtLts0OVLjpCq8Q5OYMdxR5whK7JgJpWQqMh1zIh\nYoTLatrXWA==

(the above example is when using a longer salt and longer key size, both 64)

This is due to the fact that the Base64 algorithm adds line breaks after every 76 character.

But these line breaks makes the Base64 invalid when we call the verify() method with this kind of values.

My proposal is to remove them (the line breaks)  during generation of the hash (generate() method) and also clean them out before base64 decoding (decode() method)

Rudy


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


Pbkdf2PasswordHashImpl generate() creates sometimes invalid result

Rudy De Busscher
 

During the tests I was writing for Pbkdf2PasswordHashImpl, I saw that Pbkdf2PasswordHashImpl#generate() generates a result with line breaks in it.

PBKDF2WithHmacSHA512:1024:QRyYndGzgjmZ7DT51fQ4orSJp5b1IkEaY7qFp9o0Q8ZW4GuR7A7sOQN80Dtrqh1stXjK/VSj5+TY\nZClDbdM/wQ==:VNDmODrwU/geTRbtYaQXOrraPh1XP38qM1rRJtLts0OVLjpCq8Q5OYMdxR5whK7JgJpWQqMh1zIh\nYoTLatrXWA==

(the above example is when using a longer salt and longer key size, both 64)

This is due to the fact that the Base64 algorithm adds line breaks after every 76 character.

But these line breaks makes the Base64 invalid when we call the verify() method with this kind of values.

My proposal is to remove them (the line breaks)  during generation of the hash (generate() method) and also clean them out before base64 decoding (decode() method)

Rudy


Re: Remove PlaintextPasswordHash from API?

Will Hopkins
 

Thanks, everyone. I'll go ahead and remove it, then.

On 07/26/2017 02:53 PM, Guillermo González de Agüero wrote:
But even for development, having a standard implementation that takes care of generating hashes for creating new accounts seems enough to me.

+1 for complete removal (even for RI). 

El mié., 26 de julio de 2017 20:51, Arjan Tijms <arjan.tijms@...> escribió:
No strong objections here either. I do absolutely agree that storing passwords in plain text in a production DB does border on criminal neglect.

The only somewhat excuse is that not all usage of Java EE is necessarily production usage.

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


Re: Remove PlaintextPasswordHash from API?

Guillermo González de Agüero
 

But even for development, having a standard implementation that takes care of generating hashes for creating new accounts seems enough to me.

+1 for complete removal (even for RI). 

El mié., 26 de julio de 2017 20:51, Arjan Tijms <arjan.tijms@...> escribió:
No strong objections here either. I do absolutely agree that storing passwords in plain text in a production DB does border on criminal neglect.

The only somewhat excuse is that not all usage of Java EE is necessarily production usage.


Re: Remove PlaintextPasswordHash from API?

Arjan Tijms
 

No strong objections here either. I do absolutely agree that storing passwords in plain text in a production DB does border on criminal neglect.

The only somewhat excuse is that not all usage of Java EE is necessarily production usage.


Re: Remove PlaintextPasswordHash from API?

Ivar Grimstad
 

No objections here.

Ivar

On Wed, Jul 26, 2017 at 8:08 PM Will Hopkins <will.hopkins@...> wrote:
EG:

I'm thinking we should probably remove this from the API. It's trivial for someone to implement if they need to (we could retain the Impl in the RI), but nobody should ever use this in a production setting. It should not be used even for a legacy environment -- if the plaintext for a password is known, it can be converted to a hashed format. Given the frequency with which hackers are able to get access to password databases, storing plaintext hashes constitutes security malpractice and borders on criminal negligence.

Any objections?

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

--

Java Champion, JCP EC/EG Member, JUG Leader


Remove PlaintextPasswordHash from API?

Will Hopkins
 

EG:

I'm thinking we should probably remove this from the API. It's trivial for someone to implement if they need to (we could retain the Impl in the RI), but nobody should ever use this in a production setting. It should not be used even for a legacy environment -- if the plaintext for a password is known, it can be converted to a hashed format. Given the frequency with which hackers are able to get access to password databases, storing plaintext hashes constitutes security malpractice and borders on criminal negligence.

Any objections?

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


JVM-Conference in Cologne

Werner Keil
 

Hi,

As mentioned in the call on Monday, the first edition of the www.jvm-con.com – The conference for java developers will start from 28. -  29. November 2017 in Cologne (Germany). We cordially invite you and your colleagues and friends to participate in the Call for Papers. The Call for Papers is open until 21. August 2017. The following topics have been considered for 2017 so far:

·         Java Virtual Machine (JVM)/ Java Runtime Environment (JRE)

·         Java Runtime Environment

·         JVM-Languages (Java, Scala, Jython, Kotlin, Clojure, Free Pascal, Groovy, JRuby)

·         Frontend

·         Java 9

·         Java EE 8

·         Java EE

·         Cloud Native Development

·         Microservices

·         MicroProfile

·         APIs

·         Java Security

·         Java Concurrency

·         Mobile with Java

If your favorite topic is not listed above, you are welcome to submit it anyway. The conference will have 2 conference tracks on one day with two keynotes and about 20 sessions. The second day will be the workshop day with 2-4 full or half day workshops. In order to present your topic and yourself in 2017 as best as possible, we offer the option to give a webinar or training as well. You will find more information in the submission of your session. Further information about the Call for Papers and the link to this year's submission can be found online at www.jvm-con.com/call-for-papers

It is not to be confused with a similar-named conference by the Dutch JUG (especially those from the Benelux are probably more than welcome to propose a talk there, too) 

Let me know, if you have questions. As "Java Security" is a dedicated keyword, at least one talk or even a workshop proposal by members of this EG would be welcome.
I am in the advisory board, but cannot promise for anything since it is a slightly smaller conference, but security is certainly important, so please propose something on JSR 375 if you can.

Regards,
Werner


IdentityStore/AuthenticationMechanism properties validation

Guillermo González de Agüero
 

Hi,

We already talked about validation of attributes ([1] and [2]) and canceling deployment in case of invalid ones. At that time we came to the conclusion that it was too difficult to do and that it was better not to standarize that behavior at this time.

But then with [3] I had another idea I'd like to propose to the EG. The other time we talked about the runtime validating properties for the stores. What I propose now is that identity stores themselves validate their parameters. I've thought of two posible ways:
- Add a "init() throws Exception" method to IdentityStore/HttpAuthenticationMechanism.
- Specify that an exception thrown from a @PostConstruct annotated method on an IdentityStore or HttpAuthenticationMechanism makes deployment fail. Only unchecked exceptions can be thrown on @PostConstruct methods.

This behavior is aligned with what Servlets/Singleton EJBs/eager ApplicationScoped CDI beans do. The only required change is that identity stores and authentication mechanism would need to be created at deployment time, to be able to cancel deployment if needed.

I'd go for the @PostConstruct alternative as it's the less intrusive and more "CDIish" way to do it. Changes to the spec and implementation are minimal, while providing users the ability to validate their own artifacts. This would also help [3] case reducing runtime exceptions to just unexpected ones.

What do you think?


Regards,

Guillermo González de Agüero:

[1] https://javaee.groups.io/g/javaee-security-spec/message/324
[2] https://github.com/javaee/security-soteria/issues/104
[3] https://github.com/javaee/security-soteria/pull/124


Notes from JSR-375 Expert Group Meeting 2017-07-06

Will Hopkins
 

These are my notes, such as they are, from the meeting we had a couple weeks ago.

Agenda/Notes from JSR-375 Expert Group Meeting 2017-07-06:
  • Need to finalize PFD draft this week
  • How to people feel about the PRD draft?
  • Will send out list of proposed changes tonight or tomorrow, and review draft Friday, quick review appreciated
  • Close on open issues
    • How to handle open JIRAs (at javaee) for things we won't do?
    • Open JIRA issues:
      • Hashing algorithms
      • Indirection for annotation config values?
    • Open issues from email:
      • Refactor SecurityContext?
      • Group -> Role mapping?
      • Downcasting principals
    • From my spec notes:
      • avoid dependency on jaspic from AuthException used by HAM?
      • checked exception for, e.g., network errors during validate() or getCallerGroups()?
      • qualifier and scope for HttpAuthenticatinoMechanism beans?
      • Can we really say it MUST be possible to provide a HAM in an application archive? Isn't that up to CDI?
        • need to use the bean manager that can see both application and container classes.
      • results undefined if more than one HAM supplied? or deployment error? Does CDI say? -- cdi will complain if there are two impls.
    • Other:
      • LDAP annotation attributes -- may tweak these and send proposal to list
Arjan issues:
  • remember me -- secure by default, warning in logs if is not secure
  • login to continue
Will: ejb get caller vs. servlet get caller -- follows servlet way of doing things -- returns null

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


Notes from JSR-375 EG Meeting 2017-07-25

Will Hopkins
 

Agenda/Notes from JSR-375 EG Meeting 2017-07-25:
  • Status -- where are we?
    • Soteria work needed for RI to match PFD spec:
      • Expression Language Support -- DONE
      • Add getPrincipalsByType() -- DONE
      • Remove hasAccessToWebResource(resource) -- DONE
      • Changes to signatures for HttpMessageContext -- DONE
      • Changes to notifyContainerAboutLogin to set principals correctly -- In Progress
      • Changes to bridge SAM to support AuthenticationException -- DONE
      • Add support for caller DN to built-in identity stores -- DONE
      • Support for changes to LdapIdentityStoreDefinition annotation -- DONE
      • Support for changes DatabaseIdentityStoreDefinition annotation -- In Progress (may deviate from current spec, see below)
    • Potential changes for updated PFD:
      • Fix description of RememberMe annotation -- can't be used with built-in identity stores -- DONE (on branch)
      • Describe required Credential type support for built-in identity stores (UsernamePassword required, others optional)
      • Describe permission model, required behavior, for IdentityStore.getCallerGroups()
      • Better DatabaseIdentityStoreDefinition password hashing support -- In Progress
      • Auto-apply session description for spec document -- Not Done
  • Process stuff
    • Need to get final RI changes (code complete, not necessarily all bugs) to TCK team ASAP, hopefully by tonight (TCK team is in China).
      • At risk of not meeting TCK schedule, so need simplest possible solutions for remaining technical issues.
    • Use of issues going forward
      • Haven't played with it yet, but may create a project, or maybe just some tags, so that we can manage issues specifically for milestones like generating a PFD2 draft and associated spec and API changes.
        • Will to triage issues and make sure there are open issues for all outstanding work items.
        • Should we use API repo issues to manage API changes and soteria issues for RI? Or keep it simple and just use soteria issues? -- Decision, separate issues for each repo.
      • If working on an issue, assign to yourself so others know it's being worked.
      • At some point, need to triage issues in security-spec repo.
    • Travis CI integration? -- Arjan will fix this so the checking tests work.
    • Jetbrains? No further followup yet. Will has been in touch to give them updated spec and request feedback. Suggestion: propose that they submit a PR with spec changes.
  • Technical Discussion
    • notifyContainerAboutLogin (and getCallerPrincipal())?
      • Don't need to change this, Per JASPIC, CallerPrincipalCallback can do whatever it needs here, even add multiple principals.
      • CallerPrincpal will continue to be explicitly added if provided to notify() as a Principal type or via CredentialValidationResult.
    • DatabaseIdentityStore PasswordHash
      • Will add an init() method to the interface, runtime will get dependent bean at id store init time, init the algorithm, and hand it to the identity store. Id store specific instance available internally, may specify an accessor method in a subsequent version of the spec.
    • Permission for IdentityStore.getCallerGroups()
      • Will use a generic permission (i.e., not qualified by the app context or anything else), checked only if security manager is enabled.

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


Re: Discovered tiny omission in @RememberMe

Will Hopkins
 

Yes, please.

On 07/24/2017 05:48 PM, Arjan Tijms wrote:
Hi,

After going through the API one more time I just noticed that the @RememberMe annotation is missing one attribute, namely "isRememberMe" as typed version of "isRememberMeExpression".

Normally all non-string attributes have the XYZ and XYZExpression pairs, but here there's only the expression variant. It's easy to add though. Shall I add it?

Kind regards,
Arjan Tijms

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

181 - 200 of 736