If it demonstrates how aspects of JSR 375 can work, would it make sense to
merge your collaborative effort into either the "proposal" or "examples"
repo, too?
It's a little easier to track changes and ideas in just those 2 or 3
repositories than 5 or more others.
Cheers,
Werner
On Thu, Apr 16, 2015 at 12:10 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> On Thu, Apr 16, 2015 at 10:23 AM, Adam Bien <abien_at_adam-bien.com> wrote:
> > Hi Arjan,
> >
> > thanks! It works.
> >
> > All tests are green:
> https://github.com/AdamBien/secspike/blob/master/todo-st/src/test/java/org/specspike/todo/reminders/boundary/ToDosResourceIT.java
>
> Great!
>
> What you think about the look of the code?
>
> The idea would be that the app developer can freely mix between
> HttpServerAuthModule and IdentityStore, and that both can be either
> installed at the server or be provided by the application and that for
> both a couple of default implementations are provided by the spec.
>
> Not shown yet in this prototype, but HttpServerAuthModule should
> probably be a CDI bean as well.
>
> The challenge of this EG is now to standardize this (or something like
> it, of course), and make sure it works on every server ;)
>
> Kind regards,
> Arjan Tijms
>
>
>
> >
> > cheers,
> >
> > adam
> >> On 15.04.2015, at 16:43, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> On Wed, Apr 15, 2015 at 9:31 AM, Adam Bien <abien_at_adam-bien.com> wrote:
> >>> My goal is to keep the authorization / authentication part as
> convenient, elegant and usable as only possible,
> >>>
> >>> Should we start with user name / password login implementation and
> in-memory IdentityStore? We could copy this app for each scenario and reuse
> the already existing sec examples.
> >>
> >> I quickly added security to this in a fork and did a PR ;)
> >>
> >> It's by default configured for a BASIC authentication mechanism with a
> >> username/password identity store. Optionally it can be switched to the
> >> header based authentication mechanism which uses a token identity
> >> store.
> >>
> >> The BASIC *authentication mechanism* is implemented via the following
> >> JASPIC auth module:
> >>
> >> public class BasicAuthModule extends HttpServerAuthModule {
> >>
> >> @Override
> >> public AuthStatus validateHttpRequest(HttpServletRequest request,
> >> HttpServletResponse response, HttpMsgContext httpMsgContext) throws
> >> AuthException {
> >>
> >> String[] credentials = getCredentials(request);
> >> if (!isEmpty(credentials)) {
> >>
> >> UsernamePasswordIdentityStore identityStore =
> >> getReferenceOrNull(UsernamePasswordIdentityStore.class);
> >> if (identityStore != null) {
> >> if (identityStore.authenticate(credentials[0],
> >> credentials[1])) {
> >> return
> >> httpMsgContext.notifyContainerAboutLogin(identityStore.getUserName(),
> >> identityStore.getApplicationRoles());
> >> }
> >> }
> >> }
> >>
> >> if (httpMsgContext.isProtected()) {
> >> response.setHeader("WWW-Authenticate", "Basic realm=\"test
> >> realm:\"");
> >> return httpMsgContext.responseUnAuthorized();
> >> }
> >>
> >> return httpMsgContext.doNothing();
> >> }
> >>
> >> private String[] getCredentials(HttpServletRequest request) {
> >>
> >> String authorizationHeader = request.getHeader("Authorization");
> >> if (!isEmpty(authorizationHeader) &&
> >> authorizationHeader.startsWith("Basic ") ) {
> >> return new
> >> String(parseBase64Binary(authorizationHeader.substring(6))).split(":");
> >> }
> >>
> >> return null;
> >> }
> >>
> >> }
> >>
> >>
> >> The username/password *identity store* is implemented via the
> >> following CDI bean:
> >>
> >> @RequestScoped
> >> public class TestUsernamePasswordIdentityStore implements
> >> UsernamePasswordIdentityStore {
> >>
> >> private static final long serialVersionUID = 1L;
> >>
> >> @Override
> >> public boolean authenticate(String username, String password) {
> >> return true;
> >> }
> >>
> >> @Override
> >> public String getUserName() {
> >> return "testuser";
> >> }
> >>
> >> @Override
> >> public List<String> getApplicationRoles() {
> >> return asList("USER");
> >> }
> >>
> >> }
> >>
> >>
> >>> Should we use GF 4.X as reference server?
> >>
> >> I tested the above on GlassFish 4.1 (requesting
> >> http://localhost:8080/todo/resources/todos) and it works without
> >> needing any additional config.
> >>
> >> Do note that for deploying on a stock GlassFish 4.1 a
> >> glassfish-web.xml had to be added. This is *really* unfortunate. For
> >> usability the mandatory presence of either this file or setting
> >> default group to principal mapping (see
> >> https://blogs.oracle.com/bobby/entry/simplified_security_role_mapping)
> >> just has to go.
> >>
> >> For JBoss (EAP/WildFly) such mapping file is not needed, but there a
> >> (dummy) security domain has to be added, which is again a *really*
> >> unfortunate thing and a big impediment for usability. Unrelated to
> >> security, I got a "Could not find MessageBodyWriter for response
> >> object of type: java.util.ArrayList of media type:
> >> application/octet-stream" when I requested the above mentioned URL on
> >> JBoss WildFly 8.2.
> >>
> >> On WebLogic this unfortunately doesn't work at all, since there CDI is
> >> initialized too late and thus not available to the auth mechanism.
> >>
> >> So there are still a few small (but very important!) hurdles to
> >> address to make this really user friendly and portable on all servers,
> >> but I think this is a nice start ;)
> >>
> >> Kind regards,
> >> Arjan
> >>
> >>
> >>
> >>
> >>
> >>
> >>>
> >>>
> >>> cheers,
> >>>
> >>> adam
> >>>
> >>> I broke my underarm, so my coding speed suffers a bit, but next week
> should be back to normal.
> >
>