Will give it a try tonight for tomorrow's session. Thanks for all the
recent updates.
Hope I can show most of it and equally important gather feedback from the
audience. Would be awesome if some security aware people attended it,
According to the PM who even speaks at a special Cyber Security Event it
seems pretty aware:
http://www.timesofisrael.com/netanyahu-israel-is-leading-wests-cyber-security-fight/
Kind Regards,
Werner Keil
On Tue, Dec 15, 2015 at 7:01 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> As mentioned in the thread about the working example app, I've committed
> an experimental proposal for the authentication mechanism. See
> https://java.net/projects/javaee-security-spec/lists/jsr375-experts/archive/2015-12/message/21
>
> As that thread is more about the actual example app, this one is likely
> better to discuss the actual API of the proposal.
>
> Everything combined, an application implements the new
> interface HttpAuthenticationMechanism. Just like with the identity store,
> there's no explicit registration needed. The presence of a single
> implementation of this interface is enough for CDI to pick it up.
>
> The CDI enabled "sam" can be seen in action here:
>
>
> https://github.com/arjantijms/mechanism-to-store-x/blob/master/app-db/src/main/java/test/TestAuthenticationMechanism.java
>
> This "sam" is now fully CDI enabled, and therefor can have the identity
> store injected instead of programmatically obtaining it via CDI.current();
>
> Thoughts?
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
> On Wed, Oct 21, 2015 at 12:19 PM, Darran Lofthouse <
> darran.lofthouse_at_jboss.com> wrote:
>
>> The work we are undertaking within WildFly we have some cases where
>> mechanisms require a modifiable store but these are fairly limited.
>>
>> On 15/10/15 19:05, Rudy De Busscher wrote:
>>
>>> Hi All,
>>>
>>> Is my assumption correct that (in most cases) you would use the
>>> 'read-only identity store' to determine the correctness of the
>>> credentials?
>>>
>>> Is the use of CDI.current() then the only option to get a reference to
>>> the store, or what is the relation between these 2 concepts.
>>>
>>>
>>> best regards
>>> Rudy
>>>
>>>
>>> On 15 October 2015 at 13:13, arjan tijms <arjan.tijms_at_gmail.com
>>> <mailto:arjan.tijms_at_gmail.com>> wrote:
>>>
>>> Hi
>>>
>>> On Thu, Oct 15, 2015 at 3:45 AM, Alex Kosowski
>>> <alex.kosowski_at_oracle.com <mailto:alex.kosowski_at_oracle.com>> wrote:
>>> > A. Standardize a simple authenticator, by simplifying JASPIC SAM
>>> usage:
>>>
>>> +1 on this, of course ;)
>>>
>>>
>>> > Install a SAM programmatically using a single method call (e.g.
>>> > Jaspic.registerServerAuthModule)
>>>
>>> This is by itself pretty straightforward. In the simplest version
>>> this
>>> method takes an instance of the SAM and registers that single
>>> instance
>>> as the one and only SAM for the Servlet container.
>>>
>>> An example of that can be seen here:
>>>
>>> https://github.com/javaee-samples/javaee7-samples/blob/master/jaspic/common/src/main/java/org/javaee7/jaspic/common/JaspicUtils.java#L23
>>>
>>> Many projects out there in the wild that I've seen use highly
>>> similar code.
>>>
>>> There are two things to keep in mind for this variant:
>>>
>>> 1. The SAM here is a plain class. It can -use- the CDI API via
>>> CDI.current(), but is itself not a CDI bean (it's not injectable or
>>> scoped)
>>>
>>> 2. Following 1, but perhaps good to mention explicitly; there's only
>>> a
>>> single instance of the SAM and it has to be thread-safe. Just like a
>>> Servlet. The "handler" that it gets from the container is thead-safe
>>> though.
>>>
>>> An alternative (or additional) approach is that the input paramater
>>> is
>>> a Class<T>, and we'll promise to obtain a reference to that class
>>> using CDI.
>>>
>>>
>>>
>>> > Install a SAM using an Annotation (e.g. @Authenticator(<SAM class>,
>>> > <options>) )
>>>
>>> Instead of @Authenticator it may be better to use the term
>>> @AuthenticationMechanism here, as "authenticator" is yet another term
>>> and even one that's unfortunately ambiguous in its existing usage
>>> (some servers use this term for what we now call an "identity
>>> store').
>>>
>>> Just like with the identity store, I think we have two variants here
>>> for the annotation;
>>>
>>> 1. Making an application provided SAM directly available
>>> 2. Registering a SAM that was provided by a library (or, who knows,
>>> the spec later on)
>>>
>>> Example of the first variant:
>>>
>>> @ApplicationScoped
>>> @AuthenticationMechanism
>>> public class BasicAuthModule extends HttpServerAuthModule {
>>>
>>> @Inject
>>> private IdentityStore identityStore;
>>>
>>> @Override
>>> public AuthStatus validateHttpRequest(HttpServletRequest
>>> request,
>>> HttpServletResponse response, HttpMsgContext httpMsgContext) throws
>>> AuthException {
>>>
>>> // get credendials, use identityStore, get authresult back
>>>
>>> if (httpMsgContext.isProtected()) {
>>> response.setHeader("WWW-Authenticate", "Basic
>>> realm=\"test
>>> realm:\"");
>>> return httpMsgContext.responseUnAuthorized();
>>> }
>>>
>>> return httpMsgContext.doNothing();
>>> }
>>> }
>>>
>>> The @AuthenticationMechanism may even be omitted if we say that just
>>> like with the IdentityStore there should only be one injectable
>>> "HttpServerAuthModule" on the classpath.
>>>
>>>
>>>
>>> > Simplify SAM development for servlet based authentication (e.g.
>>> > HttpServerAuthModule, HttpMessageContext)
>>>
>>> To sum up for those who haven't read all the issues; this is
>>> basically
>>> what HttpServlet is to GenericServlet.
>>>
>>> In my prototype HttpServerAuthModule is a base class that actual
>>> authentication modules have to extend. This wasn't done because of
>>> any
>>> architectural preference for base classes, but just because it was
>>> easy to prototype.
>>>
>>> One note about HttpMessageContext; this is a convenience object that
>>> can be used within a SAM, but only within a SAM. As such it's just
>>> like FacesContext in JSF or a ServletContext or even
>>> HttpServletRequest in Servlet. All those objects should not be used
>>> arbitrarily, but of course only within the context where they are
>>> valid.
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>
>