Hi,
On Fri, Mar 31, 2017 at 11:15 PM, Will Hopkins <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>
> 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>
>> 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> 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
>>>>
>>>> I also wrote an article about this a couple of years ago:
>>>>
>>>> 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/ma
>>>> ster/src/main/java/org/example/kickoff/model/producer/Active
>>>> UserProducer.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.
>>>> To post to this group, send email to jsr375-experts_at_googlegroups.com.
>>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>>> gid/jsr375-experts/CAE%3D-AhCLNv6U297cETZTGK%2B5V4MWi5LxoMyd
>>>> 0kF3oRF2am2RMQ%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.
>>>>
>>>
>>> --
>>> 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.
>>> To post to this group, send email to jsr375-experts_at_googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/jsr375-experts/CAL%2Bwt-6nmC%3DP52qSwL5iLSWUNk-%2BfT7q9C
>>> r2j1UZkGx9%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.
>>>
>>
>>
>> --
>> Will Hopkins | WebLogic Security Architect | +1.781.442.0310 <%28781%29%20442-0310>
>> Oracle Application Development
>> 35 Network Drive, Burlington, MA 01803
>>
>>
>
> --
> Will Hopkins | WebLogic Security Architect | +1.781.442.0310 <(781)%20442-0310>
> Oracle Application Development
> 35 Network Drive, Burlington, MA 01803
>
>