I'll give this some thought a little later -- it's late on a Friday
afternoon here in Massachusetts. ;) My initial reaction is that it
might be best to mirror the existing JASPIC codes exactly, rather than
introduce a translation that's subtly different, but I haven't worked
through your rationale yet, so don't have a strong opinion.
One related comment -- I presented at Devoxx last week, and an audience
member asked why there were two authenticate methods, with the only
difference being that HttpServletRequest was not required for one of
them. I didn't have a good answer -- is there a reason to have two?
Presumably, if the caller has access to the response, he/she also has
access to the request? There might be some small convenience to passing
only the response, but at the cost of clarity and simplicity.
Will
On 03/31/2017 05:55 PM, arjan tijms wrote:
> Hi,
>
> On Fri, Mar 31, 2017 at 11:15 PM, Will Hopkins
> <will.hopkins_at_oracle.com <mailto:will.hopkins_at_oracle.com>> 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.
>
>
> Okay. One important aspect here is then that, obviously, people do
> indeed look at the PRs.
>
> The most important refinement I'm working on as we speak is replacing
> the usage of the JASPIC AuthStatus by a JSR 375 defined enum.
>
> It's this enum:
>
> public enum AuthenticationStatus {
>
> NOT_DONE,
> IN_PROGRESS,
> SUCCESS,
> FAILURE
> }
>
> The following code shows how it maps to the JASPIC AuthStatus:
>
> public static AuthStatus fromAuthenticationStatus(AuthenticationStatus
> authenticationStatus) {
>
> switch (authenticationStatus) {
>
> case NOT_DONE: case SUCCESS:
>
> return AuthStatus.SUCCESS;
>
> case FAILURE:
>
> return AuthStatus.FAILURE;
>
> case IN_PROGRESS:
>
> return AuthStatus.SEND_CONTINUE;
>
> default:
>
> throw new IllegalStateException("Unhandled status:" +
> authenticationStatus.name());
>
> }
>
> }
>
>
> I'm not 100% sure yet about the NOT_DONE status, although there's some
> prior discussion about this.
>
>
> In a nutshell, if JASPIC currently authenticates the caller (sets the
> authenticated principal) OR when authentication is not mandatory and
> it does NOT authenticate the caller, it returns SUCCESS.
>
>
> At the time it made sense to specify it that way, since it simply
> means that the SAM fulfilled the policy. But in practice the "OR"
> proved to be troublesome at times, since various things (interceptors,
> filters, extensions in third party frameworks, etc) actually need to
> know which of the two cases happened.
>
>
> So the HAM can do a little bit better here and make the distinction.
> When going back to the JASPIC layer, both those separate status values
> (SUCCESS and NOT_DONE) become SUCCESS again.
>
>
>
> 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.
>
>
> That would be a good process indeed. If it's agreed to add the
> login/logout events I surely would like to volunteer to implement them
> for the RI.
>
>
> 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);
>
>
> As they were in the original issue about the SecurityContext, and we
> had agreed to include the context, and had discussed them, I thought
> it was okay to include these. Note that no other methods than those in
> the issue were added.
>
> As for the discussion, you mentioned the existence of dynamic roles
> potentially being an issue, so I addressed that in a slightly refined
> version of the original method where I added the "declared" part. This
> means that simply said only the static roles that the caller is in are
> to be returned by that method.
>
> You also mentioned JACC being potentially an issue for WLS, so
> implementation wise I abstracted from JACC and the spec text will not
> mention it either. Although I personally don't entirely agree with
> this (as JACC is a part of Java EE I feel we should not have to avoid
> it and/or abstract from it), but I hoped it would be a good compromise
> this way.
>
> On the Java EE RI (GF) this is absolutely trivial to implement, as the
> code shows. WLS can implement the minimal SPI for this if it wants to
> use the JSR 375 RI (of course if WLS choses to do its own full
> implementation then this would not matter at all and it could do
> whatever it wants).
>
> Kind regards,
> Arjan Tijms
>
>
> 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 <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