Hi,
On Fri, Mar 31, 2017 at 11:25 PM, Will Hopkins <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".
Beans can also be disabled via CDI or overridden (via the @Alternative
annotation), and that makes all the difference.
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.
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.
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.
But in general this is something to be quite careful with.
>
> 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.
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.
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>
> 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>
>> 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>
>>> wrote:
>>>
>>>> Created 30/Apr/13, that was 4 years before the day, 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>
>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> --
>>> 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 <%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
>
>