Unfortunately I don't think we can add this, or keep the API/SPI
additions recently checked into the security-api repository.
As I've noted before, we really have very little time left to wrap up
this JSR. I've agreed to keep the SecurityContext APIs that are already
spec'd, but I can't see taking on new APIs. It may seem like a small
thing to add a couple new methods here and there, but, while it's easy
enough to prototype an API, there is real work associated with each
additional function:
* Have the EG discussion about the API and get consensus that it's
useful and well-designed. Iterate.
* Write the specification.
* Ensure the API code matches the spec.
* Write the RI code, ensuring that it's integrated, and works as
designed, with Glassfish 5.0.
* Write TCK test cases.
* Write TCK code.
* Etc.
Apart from the initial design, most of this work falls to me, and a few
others, here at Oracle. (And I have other responsibilities that keep me
from spending 100% of my time on the JSR.)
Leaving aside the additional spec/RI/TCK work, there are significant
design questions with the new submissions that should at least be
discussed before the APIs are accepted. In the case of the JASPIC
events, there's also the question of whether it's appropriate to add a
JASPIC feature in this JSR, or whether that should be done in a JASPIC
maintenance release. Even if we all agreed on a design today, I'm
concerned that there's not enough time left in the schedule for a new
API to "marinate" -- often, issues with APIs only become apparent with
time and usage. We run the risk of standardizing an API that's not fully
baked, if we throw it into the spec at the last minute.
I note that our date to publish a Public Review draft is April 20 --
only about two weeks away, given that I'll need to submit the draft
several days in advance of its publication date (see full schedule
below). Meanwhile, I've only received comments on the EDR from one EG
member (thanks, Darran!), even though there are significant open issues
called out in the document.
I feel like resolving open issues with the existing APIs needs to take
priority over adding new APIs.
For the record, here is the schedule I'm working from. The end date is
fixed, determined by the overall EE 8 schedule, and the other dates are
arrived at by working backwards from the end date. There's not a lot of
time remaining, and very little slack in the schedule. (I'll be sending
this to the JCP to update the JSR 375 page, which I can't update myself.)
2017-03-13 EDR Start
2017-04-12 EDR End
2017-04-20 PR Start (Public Review)
2017-05-20 PR End
2017-05-23 PR Ballot Start
2017-05-30 TCK Complete
2017-06-05 PR Ballot End
2017-06-06 21 Day PFD Start (Proposed Final Draft)
2017-06-26 21 Day PFD End
2017-06-27 Hand FAB materials to JCP
2017-07-11 FAB Start (Final Approval Ballot)
2017-07-24 FAB End
2017-07-26 Security GA Release
I hate to be a wet blanket -- all the proposed features seem like good
ideas, and I wish we had more time to work on them -- but at this point
in the schedule I can't see adding more content. It's important that we
complete the JSR on time, with APIs that are carefully considered,
clearly and accurately specified, and able to stand the test of time.
Thanks for all of your help in accomplishing this.
Regards,
Will
On 03/31/2017 12:18 PM, arjan tijms wrote:
> Hi,
>
> On Fri, Mar 31, 2017 at 4:59 PM, Rudy De Busscher
> <rdebusscher_at_gmail.com <mailto:rdebusscher_at_gmail.com>> wrote:
>
> Hi Arjan,
>
> That would indeed a good addition for this release (EE8), as it is
> linked to the 'authentication' theme we have.
>
> The question is, what do we put as payload within the event? I
> should say the principal,
> /javax.security.CallerPrincipal/
> which we have created for the spec.
>
>
> Indeed ;) This is also almost the payload I used for the example event
> in that kickoff app;
>
> public class AuthenticatedEvent extends SecurityEvent {
>
> private static final long serialVersionUID = 1L;
> public AuthenticatedEvent(Object source, Principal principal) {
> super(source, principal);
> }
> }
>
>
>
> And next to login and logout events, I should also add a/failed
> login/ event.
>
> This allows the developers to 'block' a user when there are x
> failed attempts.
>
>
> Definitely, that's a very common request as well.
>
> There's 2 options here: an actual event called FailedLogin, or a more
> general event PostAuthenticate with Failure or so as status.
>
> Likely the FailedLogin as you proposed is better, but just throwing
> (no pun) out some options here ;)
>
> One thing to realise here is that Soteria can easily throw the events
> using CDI right before it returns the outcome to the container calling
> it. In many cases this will be "good enough", but to be actually 100%
> correct the events should be thrown by the container when it has
> actually applied (set) or removed the authenticated identity.
>
> This unfortunately requires some container specific code, such as
> shown for Undertow in the linked article.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
> Regards
> Rudy
>
>
> On 31 March 2017 at 14:35, arjan tijms <arjan.tijms_at_gmail.com
> <mailto:arjan.tijms_at_gmail.com>> wrote:
>
> Hi,
>
> One of the things that were discussed early on, but till so
> far hasn't seen much followup is throwing (CDI) events when
> the caller is authenticated (logs in) and logs out.
>
> See this issue: https://java.net/jira/browse/JASPIC_SPEC-21
> <https://java.net/jira/browse/JASPIC_SPEC-21>
>
> I also wrote an article about this a couple of years ago:
>
> http://arjan-tijms.omnifaces.org/2012/12/bridging-undertows-authentication.html
> <http://arjan-tijms.omnifaces.org/2012/12/bridging-undertows-authentication.html>
>
> An example of how these events can be used in practice is
> shown here:
>
> https://github.com/javaeekickoff/java-ee-kickoff-app/blob/master/src/main/java/org/example/kickoff/model/producer/ActiveUserProducer.java
> <https://github.com/javaeekickoff/java-ee-kickoff-app/blob/master/src/main/java/org/example/kickoff/model/producer/ActiveUserProducer.java>
>
> The simple post authenticate events (being informational only)
> are relatively well understood and something like this is
> quite often asked for and/or needed by users.
>
> I think it would be good to include this in JSR 375.
>
> Thoughts?
>
> Kind regards,
> Arjan Tijms
>
>
>
> --
> You received this message because you are subscribed to the
> Google Groups "Java EE Security API - JSR 375 - Experts" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to
> jsr375-experts+unsubscribe_at_googlegroups.com
> <mailto:jsr375-experts+unsubscribe_at_googlegroups.com>.
> To post to this group, send email to
> jsr375-experts_at_googlegroups.com
> <mailto:jsr375-experts_at_googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jsr375-experts/CAE%3D-AhCLNv6U297cETZTGK%2B5V4MWi5LxoMyd0kF3oRF2am2RMQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/jsr375-experts/CAE%3D-AhCLNv6U297cETZTGK%2B5V4MWi5LxoMyd0kF3oRF2am2RMQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Java EE Security API - JSR 375 - Experts" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to jsr375-experts+unsubscribe_at_googlegroups.com
> <mailto:jsr375-experts+unsubscribe_at_googlegroups.com>.
> To post to this group, send email to
> jsr375-experts_at_googlegroups.com
> <mailto:jsr375-experts_at_googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jsr375-experts/CAL%2Bwt-6nmC%3DP52qSwL5iLSWUNk-%2BfT7q9Cr2j1UZkGx9%2B3reWQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/jsr375-experts/CAL%2Bwt-6nmC%3DP52qSwL5iLSWUNk-%2BfT7q9Cr2j1UZkGx9%2B3reWQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
>
--
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Application Development
35 Network Drive, Burlington, MA 01803