All,
Had a great talk yesterday. At least 50-70 people (guess DevoXX Be probably
had more, not sure about FR or Uk?) in a cinema very similar to Antwerp ;-)
I invited those interested to join the mailing list or Github. Right before
my Session was one on the value of Open Source which was a good
introduction. Will Post slides on Slideshare. Thanks everyone especially
Arjan.
Regards,
Werner
Am 15.12.2015 18:48 schrieb "arjan tijms" <arjan.tijms_at_gmail.com>:
> Hi,
>
> Another update: I finally came around to implementing an experimental
> version of the simplified SAM.
>
> This version is based on the HttpServerAuthModule that was used in several
> examples before, and which in turn was based on the one from OmniSecurity.
>
> The difference is that instead of a base class, it's now an interface (as
> previously discussed). It closely follows the methods of a SAM, but the
> type implementing it is no longer a SAM itself.
>
> For now I've defined the interface as follows:
>
> public interface HttpAuthenticationMechanism {
>
> AuthStatus validateRequest(HttpServletRequest request,
> HttpServletResponse response, HttpMsgContext httpMessageContext) throws
> AuthException;
>
> default AuthStatus secureResponse(HttpServletRequest request,
> HttpServletResponse response, HttpMsgContext httpMessageContext) throws
> AuthException {
> return SEND_SUCCESS;
> }
>
> default void cleanSubject(HttpServletRequest request,
> HttpServletResponse response, HttpMsgContext httpMessageContext) {
> httpMessageContext.cleanClientSubject();
> }
>
> }
>
> See
> https://github.com/arjantijms/mechanism-to-store-x/blob/master/jsr375/src/main/java/javax/security/authenticationmechanism/http/HttpAuthenticationMechanism.java
>
>
> The JSR 375 CDI extension scans for the one and only implementation of
> HttpAuthenticationMechanism, and if found installs a bridge SAM for it that
> calls this implementation for each method: E.g. for validateRequest it
> looks like this:
>
> public AuthStatus validateRequest(MessageInfo messageInfo, Subject
> clientSubject, Subject serviceSubject) throws AuthException {
> HttpMsgContext msgContext = new HttpMsgContext(handler, options,
> messageInfo, clientSubject);
> return CDI.current()
> .select(HttpAuthenticationMechanism.class).get()
> .validateRequest(msgContext.getRequest(),
> msgContext.getResponse(), msgContext);
> }
>
> Just like the identity store, applications can now use a "sam" by only
> having an implementation of HttpAuthenticationMechanism on their classpath.
> The code now looks much simpler too. E.g. the example SAM used before is
> simplified into this:
>
> @RequestScoped
> public class TestAuthenticationMechanism implements
> HttpAuthenticationMechanism {
>
> @Inject
> private IdentityStore identityStore;
>
> @Override
> public AuthStatus validateRequest(HttpServletRequest request,
> HttpServletResponse response, HttpMsgContext httpMessageContext) throws
> AuthException {
>
> if (request.getParameter("name") != null &&
> request.getParameter("password") != null) {
>
> // Get the (caller) name and password from the request
> // NOTE: This is for the smallest possible example only. In
> practice
> // putting the password in a request query parameter is highly
> // insecure
> String name = request.getParameter("name");
> Password password = new
> Password(request.getParameter("password"));
>
> // Delegate the {credentials in -> identity data out} function
> to
> // the Identity Store
> CredentialValidationResult result = identityStore.validate(
> new UsernamePasswordCredential(name, password));
>
> if (result.getStatus() == VALID) {
> // Communicate the details of the authenticated user to the
> // container. In many cases the underlying handler will
> just store the details
> // and the container will actually handle the login after
> we return from
> // this method.
> return httpMessageContext.notifyContainerAboutLogin(
> result.getCallerName(), result.getCallerGroups());
> } else {
> throw new AuthException("Login failed");
> }
> }
>
> return httpMessageContext.doNothing();
> }
>
> }
>
> See:
> https://github.com/arjantijms/mechanism-to-store-x/blob/master/app-db/src/main/java/test/TestAuthenticationMechanism.java
>
> One partially unsolved problem, which I happen to have discussed with Ron
> Monzillo some time ago, is how module options should neatly arrive in this
> CDI enabled SAM. Currently they can be obtained from the HttpMsgContext.
> Ideally though, you may want to inject them and do something in the
> @PostConstruct method.
>
> But as those module options are per SAM, and there can be multiple SAMs,
> even of the same class type, I was struggling a little on how to support
> that.
>
> CDI itself has something like this with their Bean<T>, and they use a
> unique ID for that that is typically set to just the classname, but can be
> more eloborate if needed. Typically the values of constructor parameters
> are included if the Bean<T> has one. See e.g.
> https://github.com/javaserverfaces/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/cdi/CdiProducer.java#L97
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Dec 14, 2015 at 11:43 AM, Werner Keil <werner.keil_at_gmail.com>
> wrote:
>
>> Hi,
>>
>> Thanks for the update. I will try it in WildFly at some point, but
>> especially the current client and environment (where especially some ideas
>> in the JSR like "roles allowed" found here
>> https://github.com/javaee-security-spec/javaee-security-examples would
>> be of interest in theory) are not even able to use WildFly or Java EE 7 and
>> probably won't be for another decade, so it is not so urgent before
>> codemotion.
>>
>> Kind Regards,
>>
>> Werner Keil
>>
>> On Mon, Dec 14, 2015 at 11:21 AM, arjan tijms <arjan.tijms_at_gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> On Mon, Dec 14, 2015 at 12:25 AM, Werner Keil <werner.keil_at_gmail.com>
>>> wrote:
>>>
>>>> It works well in Glassfish 4, Wildfly 10 did not,
>>>
>>> [...]
>>>
>>> Yes, I did not modify it
>>>>
>>>
>>> Again a life "proof" of how important it is that WildFly does not
>>> require the modification ;)
>>>
>>> You're not the first one to fall into this. Quite a few people think it
>>> doesn't work on JBoss, since this modification is so non-obvious.
>>>
>>> Or the modification is done once, and then later a new install of JBoss
>>> (WildFly) is done and the modification is forgotten again (this happens all
>>> the time over at the Java EE 7 samples project for the CI).
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>
>