Also the CallerDetails SPI -- basically, anything not already described
in the EDR.
On 03/31/2017 05:15 PM, Will Hopkins wrote:
> Tweaks to existing APIs are fine, although, again, I think any changes
> at this point need to be discussed and agreed before check-in. I think
> a good process is probably to work from the existing spec and meet to
> agree responses to comments on the spec, and then designate who will
> update the api or ri code.
>
> Besides the login/logout events, I had in mind these recent additions
> to SecurityContext:
>
> List<String> getAllDeclaredCallerRoles();
>
> boolean hasAccessToWebResource(String resource);
> boolean hasAccessToWebResource(String resource, String... methods);
>
> Will
>
>
>
> On 03/31/2017 04:53 PM, arjan tijms wrote:
>> Hi,
>>
>> On Fri, Mar 31, 2017 at 10:28 PM, Will Hopkins
>> <will.hopkins_at_oracle.com <mailto:will.hopkins_at_oracle.com>> wrote:
>>
>> Unfortunately I don't think we can add this, or keep the API/SPI
>> additions recently checked into the security-api repository.
>>
>>
>> Which things are you specifically referring to?
>>
>> There were not any totally new features checked in as far as I can
>> see, only things that were discussed and are being refined.
>>
>> Like for instance the AuthStatus return codes that are being replaced
>> by enums is the result of that discussion. The functionality is
>> identical, but instead of JASPIC status codes via static instances,
>> enums are used. There's still some debate possible about the exact
>> naming of these, but that won't influence semantics or features.
>>
>> I do agree not to over hastily add large new things, but the little
>> time we still have can be put to good use by refining existing things
>> that came out of discussions, such as the enum I mentioned and the
>> security context mentioned in the previous mails.
>>
>> Events is a question, which is why I asked about it. A
>> logged-in/logged-out event is relatively simple, reasonably well
>> understood and agreed to by the EG. There are existing
>> implementations both by AS vendors (e.g. Undertow) as well as
>> security frameworks (e.g. my own OmniSecurity), which have been used
>> in practice for many, many years.
>>
>> If we can't get them in because there is no time, then that's no
>> problem. But if there's only little time I personally think we should
>> not have to shy away from putting in the work.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>> 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 <tel:%28781%29%20442-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