Arjan,
On 03/31/2017 06:19 PM, arjan tijms wrote:
> Hi,
>
> On Fri, Mar 31, 2017 at 11:25 PM, Will Hopkins
> <will.hopkins_at_oracle.com <mailto:will.hopkins_at_oracle.com>> wrote:
>
> This is specified in the EDR, based on discussion on the experts list.
>
> The way I specified it is that the servlet container will
> configure the SAM required for HttpAuthenticationMechanism IFF the
> <login-config><auth-method> for the servlet is set to AUTHMECH (as
> opposed to BASIC, FROM, or CERT). The reason for this is that
> applications must be able to specify how they want to
> authenticate, per the servlet spec. If the mere existence of
> HttpAuthenticationMechanism somewhere in classpath triggers that
> behavior, it may override the application's choice (or, at best,
> allocate unused resources in the container).
>
>
> Yes and no ;) On the one hand it's good to have an extra entry in the
> <login-config> that unites the build-in mechanisms and the custom ones.
>
> On the other hand, it's not just the existence of the bare type on the
> class path, is the type being available as an "enabled bean".
Understood.
> Beans can also be disabled via CDI or overridden (via the @Alternative
> annotation), and that makes all the difference.
I need to read through the CDI spec again to make sure I understand
what's possible for an app to manage.
On a separate topic, it occured to me that it might be useful to define
a security context in CDI, where permissions were checked during
injection, as a means to control access to sensitive functions, but
that's something that will have to wait for the next JSR.
> On top of that, it's the application's choice to have such a type on
> its class path. If some third party library would infringe in some way
> and force an HttpAuthenticationMechanism to become used then the
> application should not use such library.
Not always. There is also the server classpath. Different vendors manage
the classpath exposed to applications in different ways, and there could
be classes in classpath that the application has no control over.
> This maybe sounds naive, but it's not different from what already
> happens in practice. An @WebListener can use the JASPIC factory to
> install a SAM. There too, the mere presence of such @WebListener
> annotated class will cause the mechanism (the JASPIC SAM) to be installed.
Yes, it's possible to do that; my thought was that it was useful for the
app to declare its intent -- otherwise, there's a potential conflict
between web.xml and what's going on with HAMs. We can always reconsider.
> Additionally, did you try to implement <login-config><auth-method> in
> GF and let Soteria make use of it? It must be realised that
> login-config appears in web.xml, so CDI extensions cannot see that. In
> case of Soteria, the CDI extension only prepares the necessary beans
> and eventually the bridge SAM is installed from a
> ServletContainerInitializer, which does have the ServletContext.
I haven't tried to implement it yet, but I was assuming that each
servlet container would need explicit integration, so that it knew how
to handle AUTHMECH -- hence my initial comment about soteria being
integrated with Glassfish. There is an obvious advantage to not having
that dependency, though.
> But in general this is something to be quite careful with.
It requires explicit integration -- is there another reason you suggest
being careful?
> On a related note, I think we need some way of ordering or
> prioritizing when there are multiple instances of, e.g., HAMs or
> IdentityStores, in classpath,
>
> The HAM is simple. Only one enabled bean implementing the
> HttpAuthenticationMechanism interface can be active. If there are more
> it's a definition error and the container will not start. There was a
> proposal for handling multiple HAMS (or actually, a version of the HAM
> suitable for cooperating when multiple instances are present, but
> there unfortunately was no concrete followup to that.
So what happens if there's one in the app and one on the system
classpath? I agree there should only be one, but we may need to think
through how to select the proper one if multiple HAMs are visible for
some reason.
> For the multiple IdentityStores, this is Rudy's territory, but if you
> look at the interface it already has a priority. The default handler
> will try them in the order of their priority until the first one
> succeeds (iterate until succeed is used in other frameworks as well,
> if I'm not mistaken this is Spring Security's default as well).
>
> and potentially excluding some instances (esp. for
> IdentityStores). Maybe there are obvious ways to do this -- I'm
> pretty new to CDI -- but, applications need to be able to ensure
> that only the IdentityStores they want are being used at runtime,
> even when others exist in the system.
>
>
> There are indeed various ways to do this, and CDI has build-in
> mechanisms for that. It's nevertheless a good idea to discuss this,
> test it, and clarify / refine where needed.
Right. I just want to make sure we're agreed on what the recommendation
is for an app that wants to ensure it uses only the IS(es) it wants. The
priority is helpful for ordering, but not for exclusion, which will
often be wanted; there was a comment to that effect from one of the
attendees at Devoxx.
Will
>
> Kind regards,
> Arjan Tijms
>
>
>
> Will
>
>
> On 03/31/2017 04:56 PM, arjan tijms wrote:
>> Hi,
>>
>> On Fri, Mar 31, 2017 at 10:49 PM, Will Hopkins
>> <will.hopkins_at_oracle.com <mailto:will.hopkins_at_oracle.com>> wrote:
>>
>> I think we have a similar issue w.r.t. Soteria -- the web
>> container needs to configure a JASPIC AuthConfigProvider when
>> it sees AUTHMECH in <login-config>.
>>
>>
>> Sorry, could you elaborate on that?
>>
>> A (bridge) SAM is installed by the CDI extension when an
>> HttpAuthenticationMechanism is discovered on the class path. I'm
>> not really sure what you mean with AUTHMECH in <login-config>.
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>> On 03/31/2017 03:24 PM, arjan tijms wrote:
>>> Hi,
>>>
>>> The JACC and JASPIC repos are basically GlassFish, right?
>>> Especially JASPIC is a little hard to implement as a RI,
>>> since it more or less tells a Servlet container or EJB
>>> container (for SOAP) what to do.
>>>
>>> But GlassFish still isn't officially on GitHub, is it?
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>> On Fri, Mar 31, 2017 at 9:01 PM, Will Hopkins
>>> <will.hopkins_at_oracle.com <mailto:will.hopkins_at_oracle.com>>
>>> wrote:
>>>
>>> My understanding is the jacc and jaspic repos are
>>> currently on github and will be kept (or in the case of
>>> the framemaker spec source, kept in an internal
>>> repository).
>>>
>>>
>>> On 03/31/2017 12:19 PM, arjan tijms wrote:
>>>> Hope so :O
>>>>
>>>> On Fri, Mar 31, 2017 at 3:56 PM, Werner Keil
>>>> <werner.keil_at_gmail.com <mailto:werner.keil_at_gmail.com>>
>>>> wrote:
>>>>
>>>> Created 30/Apr/13, that was 4 years before the day,
>>>> java.net <http://java.net> hosting will go down for
>>>> many projects.
>>>>
>>>> Hoping, the JASPIC SPEC also being Sun/Oracle led
>>>> will remain after April 30?;-)
>>>>
>>>> Kind Regards,
>>>> Werner
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Mar 31, 2017 at 2:35 PM, 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> 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 <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