Dear All,
A little follow-up. I'll also plan to upload the slides either today or
over the weekend.
The app-db example feels like something gets stuck, either the data source
is no longer accessible or similar. Even adding and removing the app to
GlassFish 4 did not help. Only when I rebuilt everything from scratch,
stopped and started GlassFish it seems to have adjusted itself. Maybe
something to look into if it can be reproduced (if only on GlassFish)
The other variants worked fine so the session was not too interrupted when
one URL did not work.
One question I'm not entirely sure, if it's applicable was, if vendors of
JCE implementations were to adopt JSR 375. Maybe it's simply the
"java.security" package name that created such impression. The only area
which I brushed answering someone else's question was, that at least in
production where passwords aren't masked using aliasing the actual password
store should always be encrypted, too.
Not from Tel Aviv, but the host of Hackergarten Zürich, Oliver Nautsch
asked based on actual needs we help the current client meet on Java EE 6
with proprietary extensions to CDI and other frameworks built in-house.
Taking the "Movie" DB test case
https://github.com/javaee-security-spec/javaee-security-examples/tree/master/roles-allowed-and-runas
he hinted, whether it was possible to add a "content aspect" to the
SecurityContext / RunAs. Say "Manager1" could only manipulate or see movies
by "Quentin Tarantino" while "Manager2" could only do so for "Joel Coen".
Actually looking at the large PDF Alex presented at least in Paris (and
probably also London or JavaOne?) this sounds like involving "Dynamic Role
Mapping" with roles like "EDIT_ACCOUNTS", "CLOSE_ACCOUNT", etc. If this was
done on a fine grained level like "EDIT_TARANTINO_FILMS" vs.
"EDIT_COEN_FILMS" just to give an example (or say "VIEW_ADULT_FILMS" based
on a person's age;-) it might go in the direction of what the client uses
here and Oliver suggested.
Kind Regards,
Werner
On Thu, Dec 17, 2015 at 5:24 AM, Werner Keil <werner.keil_at_gmail.com> wrote:
> 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
>>>>
>>>>
>>>>
>>>
>>