A basic implementation of basic access authentication using JASPIC
- Get link
- Other Apps
Basic access authentication is a crude mechanism to authenticate that's part of the HTTP standard. It allows both an agent to send username/password credentials and a server to request the agent to authenticate itself. This happens in a simple but standardized way.
The mechanism can be easily implemented using Java EE's JASPIC and a sprinkle of utility code from the experimental OmniSecurity project (which is currently being discussed as one of the possible options to simplify security in Java EE 8).
A basic implementation looks as follows:
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; } }Full code in the OmniSecurity repo
Using injection, the example can be simplified a little and will then look as follows:
public class BasicAuthModule extends HttpServerAuthModule { @Inject private UsernamePasswordIdentityStore identityStore; @Override public AuthStatus validateHttpRequest(HttpServletRequest request, HttpServletResponse response, HttpMsgContext httpMsgContext) throws AuthException { String[] credentials = getCredentials(request); if (!isEmpty(credentials) && 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; } }
Note that the JASPIC auth module as shown here is responsible for implementing the client/server interaction details. Validating the credentials (username/password here) and obtaining the username and roles is delegated to an identity store (which can e.g. be database or LDAP based).
Arjan Tijms
- Get link
- Other Apps
Popular posts from this blog
JSF 2.3 released!
After a long and at times intense spec and development process the JSF 2.3 EG is proud to announce that today we've released JSF 2.3 . JSF (JavaServer Faces), is a component based MVC framework that's part of Java EE. JSF 2.3 in particular is part of Java EE 8. Major new features in JSF 2.3 are a tighter integration with CDI, support for WebSockets, a really cool component search expression framework (donated by PrimeFaces ), basic support for extensionless URLs, and class level bean validation. The age old native managed beans of JSF 2.3 have finally been deprecated (although they are still available for now) in favour of CDI. It's expected that these will be fully removed (pruned) in a future release. The JSF 2.3 EG would like to thank everyone who contributed to JSF in whatever way, by creating bug reports, testing builds, providing comments and insights on the mailinglist and contributing code. Without those community contributions JSF 2.3 would not have been
Dynamic beans in CDI 2.0
A while ago we wrote about CDIs ability to dynamically add Bean<T> instances to the CDI runtime. A Bean<T> is a kind of factory for beans, that makes types available for injection, lookup via the bean manager , or by referencing them in expression language. CDI producers (via the @Produces annotation) fulfil a somewhat similar role, but they essentially only make the "create instance" method dynamic; the rest (like scope, types, etc) is more or less static. A programmatically added Bean<T> essentially makes all those aspects dynamic. As the previous article showed, dynamically adding such Bean<T> is a bit more work and it's quite verbose, as well as a little complex as the developer has to find out what to return as a default for various methods that are not directly of interest. CDI 2.0 has addressed some of the above issues by providing a very convenient builder that not only makes creating a Bean<T> instance far less verbose, bu
Dynamically adding an interceptor to a build-in CDI bean
In Java EE's CDI, beans can be augmented via 2 artefacts; Decorators and Interceptors . Decorators are typically owned by the application code and can decorate a bean that's shipped by the container ( build-in beans ) or a library. Interceptors are typically shipped by a library and can be applied (bound) to a bean that's owned by the application. So how do you bind a library shipped interceptor to a library shipped/build-in bean? In CDI 1.2 and before this wasn't really possible, but in CDI 2.0 we can take advantage of the new InterceptionFactory to do just this. It's not entirely trivial yet, but it's doable. In this article we'll demonstrate how to apply the @RememberMe interceptor binding from the new Java EE 8 Security spec to a build-in bean of type HttpAuthenticationMechanism , which is from the Security spec as well. First we configure our authentication mechanism by means of the following annotation: @BasicAuthenticationMechanismDefin
Comments
Post a Comment