Hi Werner,
I intentionally omitted my personal groupId and package, so we can push the example wherever you like.
However the goal of this app is to keep the amount of security code as low as possible,
cheers,
adam
> On 16.04.2015, at 14:01, Werner Keil <werner.keil_at_gmail.com> wrote:
>
> 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.
> >
>