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.