On Sat, Apr 1, 2017 at 12:53 AM, Will Hopkins <will.hopkins_at_oracle.com>
wrote:
> 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>
> 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.
>
There's quite a lot that's possible. CDI EG member Emily did a great write
up here that's quite easy to digest even if you're not that deep into CDI
yet:
https://developer.ibm.com/wasdev/blog/2016/07/27/6-reasons-try-cdi-1-2
But basically you can provide your own override for whatever is being
enabled from whatever location, and you can exclude specific classes or
even entire packages all together.
> 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.
>
Do you mean an interceptor for a method? Kinda like @RolesAllowed?
That was indeed talked about a lot, but unfortunately not spec'ed or
implemented.
> 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.
>
The server classpath is normally not scanned by CDI. I'm not 100% sure how
this is done internally, but I assume it's part of the integration of CDI
into a server. CDI is very particular about the archives (called bean
archives in CDI terminology) that it scans. If you are on the server class
path, you have to do special things to get your classes recognised by CDI
(basically you add them programmatically, see the class
org.glassfish.soteria.cdi.CdiExtension in Soteria.
> 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.
>
Yes, it's indeed something to consider, and there's an existing issue in
the JSR 375 JIRA that kinda asks this.
> But in general this is something to be quite careful with.
>
> It requires explicit integration -- is there another reason you suggest
> being careful?
>
It's timing and mutual dependencies really. One "module" has to be booted
before the other. So if you're not careful and define something so that a
CDI extension must be able to use a Web Container artefact when it boots
up, you essentially say that the Web Container must be booted before CDI.
But if the Web Container then specifies that it must be able to use
something from CDI when it boots up, you say CDI must be made available
first. Hence, a somewhat impossible situation.
We got burned by this in JSR 372 (JSF), but were able to correct it before
going final, but JPA ran into similar issues and now some implementations
have to run through hoops to get things running. See e.g.
https://java.net/jira/browse/JPA_SPEC-70 and
https://issues.jboss.org/browse/WFLY-2727
> So what happens if there's one in the app and one on the system classpath?
>
The HAM on the system classpath won't be scanned automatically by CDI. As
mentioned above, it's internal integration magic already takes care of
this. Since the HttpServletAuthentication module is a new interface, it
comes with the requirement that regular jars containing it should be
careful about just putting it in there without the @Typed annotation
restricting it.
It's probably a very good idea to document this correctly.
For example, the provided FormAuthenticationMechanism contains this:
@AutoApplySession // For "is user already logged-in"
@LoginToContinue // Redirects to form page if protected resource and
not-logged in
@Typed(FormAuthenticationMechanism.class) // Omit
HttpAuthenticationMechanism type so it won't qualify directly as mechanism
public class FormAuthenticationMechanism implements
HttpAuthenticationMechanism, LoginToContinueHolder {
(note that it would normally not be needed for a type in a "container jar"
(jar on the server class path) to have the @Typed, but here
FormAuthenticationMechanism is added explicitly to CDI for its
interceptors, which in CDI 1.2 could not be added programmatically).
> 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.
>
True, great care must be taken here, but as mentioned it's not just about
the type being visible, but about CDI enabling the bean, which has much
more restrictions and much more interactions points than just a type on the
class path.
> 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.
>
Indeed, again that's an extremely good and valuable question.
We should document this as carefully as we can. From prior discussions came
the idea that IdentityStores in (third party) jars providing many stores
(like e.g. component libraries do for JSF), have these identity stores in
the not-activated state by default, e.g. by having the @Typed annotation on
them and/or restricting these to be scanned automatically via their
embedded beans.xml.
Then, providing e.g. an XYZStoreDefinition annotation to configure and
enable these implementations from the application.
So only the application itself should have direct implementations of these
interfaces without restrictions available. Jars should only contain
restricted versions.
Should a misbehaving jar have a non-restricted version anyway, then the
main application can override (via @Alternative) or exclude that one
explicitly.
There was a lot of discussion prior to this, mainly because it was not just
about enabling identity stores from third party archives, but also how to
configure them. Most stores provided by third parties are pretty useless
without configuration. Some wildly different variants were proposed
initially where stores had elaborate configuration lookup mechanisms and
what have you.
Kind regards,
Arjan Tijms
>
>
> 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>
>> 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 <%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
>
>