Spring Boot JWT

In my earlier posts, I described how to do authentication and authorization for a custom database schema - with Spring Security and PicketLink. 

In this post, I use the same custom schema to show how to use JWT with Spring Boot.

Most of these are covered in https://medium.com/wolox/securing-applications-with-jwt-spring-boot-da24d3d98f83

I build on top of this by tweaking it to use the same schema as used in my earlier post where the password is kept in a separate table:

A simple one, with a table to store the user info, a separate related table to store password (this is useful because, when bringing back user from DB, we don't need to bring back the password related info). A master table for role and another table to associate the roles for a user.

I write corresponding JPA entities for these tables. Importantly, I don't have a relation from AppUser to UserPassword entity (it's the other way around) - simply because, as mentioned above, I don't want to bring back password information when I load user. Same applies in case of roles too. One of the basic concepts to remember about security is that, information should not be provided unless and until it is asked for (strictly on a need-to-know basis).

So, how do we encrypt the password and store the same in DB? Spring provides excellent support for encoders. So, we declare a bean in the config file, such as:

@Bean
public PasswordEncoder passwordEncoder() {
  return new BCryptPasswordEncoder();
}

Let us now look at how to create an user with password and associate a role. We can create the entities and persist with Spring Data JPA repository:

String role="ADMIN";

AppUser appUser = new AppUser();

appUser.setLoginName(email);

...

appUserRepository.save(appUser);

UserRole userRole = new UserRole();

userRole.setAppUser(appUser);

userRole.setRole(roleMasterRepository.findByName(role));

userRoleRepository.save(userRole);

UserPassword userPassword = new UserPassword();

userPassword.setAppUser(appUser);

userPassword.setPasswordHash(passwordEncoder.encode(password));

userPasswordRepository.save(userPassword);

The above block of code can be placed within a transaction and we can call this service from wherever user creation needs to be done.

For the user authentication to work, we need to wire a authentication provider which can be  a DaoAuthenticationProvider as we are storing the info in a database. We need to pass an service to this provider which implements org.springframework.security.core.userdetails.UserDetailsService. 

We also need to set the password encoder which is same as we saw above. The UserDetailsService is an interface, so we need to override the method loadUserByUsername() which should return a org.springframework.security.core.userdetails.UserDetails instance. 

So, we create a class which implements UserDetails interface. I have named this as UserLoginDto and I pass the AppUser object and the role of the user. Using this the overridden methods can return corresponding values. For example, the method isEnabled() can simply return appUser.isActive().

Most importantly, we have to override the getAuthorities() method which needs to return the list of roles assigned for the user. Since we have retrieved the roles for the user from the DB, we can use that to build the Set and return it 

(note: I have used only only role per user in this example, we can easily expand on that).

public class UserLoginDto implements UserDetails {

  public UserLoginDto(AppUser appUser, String passwordHash, AppRole appRole) {

    this.appUser = appUser;

    ...

   }

  @Override

  public Collection<? extends GrantedAuthority> getAuthorities() {

    Set<RoleGrantedAuthority> roleSet = new HashSet<>();

    roleSet.add(new RoleGrantedAuthority("ROLE_"+ appRole.toString()));

    return roleSet;

  }

  @Override

  public boolean isEnabled() {

    return appUser.isActive();

  }

  ...

}

We do the configuring for authentication manager, password encoder all in the class WebSecurityConfig (the one annotated with @EnableWebSecurity).

As we are building this for HTTP RESTFul services, we need to have an endpoint to which users will make a REST call and get back a JWT token. And then, we will need to have a filter which will intercept all REST calls and check if the token is valid or not.

So, for the first part, we can simply write a filter which extends org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter.

We need to override two methods: attemptAuthentication, successfulAuthentication

The first method is called when authenticating the user. But, as explained above, we are authenticating via an endpoint. So, what is the endpoint?

As we're extending the Spring's internal UsernamePasswordAuthenticationFilter, by default, Spring sets the endpoint as '/login'. We can change this endpoint to something else with a call to (in the constructor):

super.setFilterProcessesUrl("/authenticate"); 

So, here, I have set the auth endpoint to 'authenticate'. When the user hits the endpoint, as a POST request with body like:

{ "username": "user1", "password": "pwd1"}

Spring Spring calls our attemptAuthentication method. We need to first read the body from the request (JSON parse). And then we call the getAuthenticationManager().authenticate. This will in turn call our authentication manager (which we configured earlier) which uses our UserService (which makes JPA calls to our custom database to load the user along with the password hash).

If the auth is successful, Spring calls our  successfulAuthentication method. It is in this method where we need to create the JWT token.

We're making use of the jjwt library to create the JWT token. We set the login name as the subject in the token. We are also setting the role that the user is assigned to in the claims part. This role information is needed and useful for the caller. We're also setting the expiration time for the token.

We are reading the key hash needed for the JWT token from the properties file and are using it. Likewise, the expiration time is also read from properties file (set in minutes). In the response header, we set the token. Once the user gets back the token, they can use it in subsequent requests. This has to be set in the request header 'Authorization' with the format 'Bearer <token>'.

For subsequent requests, we need to write a filter which should check the token validity. Allowing/disallowing an URL and also allowing specific calls for specific roles are all set in the usual manner in the WebSecurityConfig (this is standard Spring Security stuff).

For URL based authorization, we can set it up in the security config,such as:

.antMatchers("/unsecured/*").permitAll()

.antMatchers("/general/*").authenticated()

.antMatchers("/normal/*").hasRole(AppRole.USER.toString())

.antMatchers("/admin/*").hasRole(AppRole.ADMIN.toString())

I have named the filter for token verification as, well, TokenVerificationFilter. This class extends the Spring org.springframework.security.web.authentication.www.BasicAuthenticationFilter class which extends the org.springframework.web.filter.OncePerRequestFilter.

We need to override the doFilterInternal method. We read the token from the header here and call the parseClaims method of the jjwt library. This call verifies the signature and also checks if the token has expired (by checking the expiration time). If the token is valid, we set the user details in the Spring security context, like:

SecurityContextHolder.getContext().setAuthentication(authentication);

We set these two filters in the WebSecurityConfig such as:

.addFilter(new AuthenticationFilter(keyHash, expMinutes,  authenticationManager()))

.addFilter(new TokenVerificationFilter(keyHash, authenticationManager()))

The complete source code for this post is available in my github repo

References: 

https://www.toptal.com/spring/spring-security-tutorial

https://medium.com/wolox/securing-applications-with-jwt-spring-boot-da24d3d98f83

Nifi Simple Example for Wait Notify

In this post, I try to provide a simple example to demonstrate how wait/notify works in nifi. We're going to look at a scenario, where there is a list of files to be processed. But, we want Nifi to process the files one at a time (or say max n at a time) due to downstream performance restrictions. We're going to use 'GenerateFlowFile' to generate the scenario where there are lot of files to be processed.

We then connect this directly to a 'Wait' processor. The wait processor waits for the signal from a corresponding processor. When it recieves the signal, it proceeds via the 'success' relationship. So, we first 'route' the expired/error relationship to a simple 'LogMessage' processor which just logs a message. The 'wait' relationship is terminated.

The 'success' relationship moves to the next step of actually processing the file. For our illustration purposes we just use a 'LogAttribute' processor to simulate the processing of the file. In our case, we log the flowfile name. This completes our first part.

The wait processor needs the 'DistributedCache' services (we can set this up easily). I use a signal identifier 'testSignal'. This signal name will have to be used in the 'Notify' processor too.

We can actually run the flow now. The 'GEnerateFlowFile' will crank out files and we can see all of them actually waiting. The 'queue' from Gen to 'Wait' will be filled up.

Now, let's come to the notify part. The scenario that I am trying to simulate is like: we get a hit/response from an external source and for every hit we can process one file. To demonstrate this, I am going to use a 'HandleHttpRequest' processor. This starts a HTTP server listening for incoming requests. On getting a request, we route the 'success' to 'Notify' processor which uses the same signal text. The success of 'Notify' leads to 'HandleHttpResponse' which then completes the http request with a response code of 200.

 We can now run the entire flow. Using curl we can hit the endpoint like, http://localhost:5050 as this is a simple get request (alternatively you can paste the URL in the browser and hit refresh). If we tail the nifi-app.log file, we can see that, for every hit we do via curl/browser, the wait releases one file and the file name gets printed in the log.

The template for this example is available in my github repo.

Spring Boot Project with Angular - Development & Build

This blog post is to explain how to build a Spring Boot application with Angular as the frontend UI with Maven as build tool.

Goals:
1) During development run the server separately (spring-boot with live reload)
2) During development run the client separately (Angular with live reload)
3) During dev, Angular UI should be able to call the Sprint Boot RESTFul endpoints even when running separately
4) Build should however be a single Spring Boot jar with UI working as usual (without any change to REST calls).


We first create a multi-module Maven project named 'spring-boot-ang-sample' with pom packaging with includes two child modules, like:
<modules>
  <module>spring-boot-ang-sample-ui</module>
  <module>spring-boot-ang-sample-service</module>        
</modules>


There is nothing much else in the pom. We then create the Spring Boot project 'spring-boot-ang-sample' which is a regular spring boot project with devtools included for live reload. We also create a rest controller class with endpoint api/time/local which just returns a simple JSON with server's time, like:
{"type":"Local","serverTime":"2019-12-24T14:26:21.501"}

We can run this project with mvn spring-boot:run and when we hit localhost:8080/api/time/local we should see the response as above. Now, we are able to do the dev-test cycle for the server.

Next, we create the Angualar project 'spring-boot-ang-sample-ui'. We do this with Angular cli commands, like 'ng new'. This will create the regular angular project and we can run this with ng serve. We can then use the UI at localhost:4200. The changes we make to the UI will reflect with live reload.
The UI code makes calls to the server end points. But, we have a catch here. The server runs in a different port so, but, the calls from within Angular will go only to 4200 or the port which client runs.

Angular provides a nice feature to proxy calls to server: proxying

This is a very useful feature. So, we will make use of this to setup a proxy file wherein, all the calls for 4200/api will goto 8080. This helps us to run client and server separately in dev mode and can develop the interaction freely without worrying about code changes.

When building the project (for deployment), we will make use of the 'frontend-maven-plugin' from 'com.github.eirslett'. This plugin installs node and runs the build for the project. This is useful if you are running the build from say Jenkins where there is no node currently installed.

Remember that the 'spring-boot-ang-sample-ui' project is just an Angular project. So, let's first create the pom.xml so that it becomes a child module of the 'spring-boot-ang-sample' parent project.

Next, we change the angular output path of the angular build to go and reside in the 'spring-boot-ang-sample-service' project under 'src/main/resources/static'. This is a requirement for a spring-boot project to serve web pages. Note that we're not placing it within src/main/resources directly as the Java project resources can be kept separate and clean. The output path is changed, like:
"outputPath": "../spring-boot-ang-sample-service/src/main/resources/static",

Now, when run 'ng build' or when we run mvn clean install on the UI project, the distribution goes and sits in the static folder of the Spring-boot project. Next, when we build the Spring boot project as a jar (mvn clean install), the static resources (web pages ) become part of the jar. After the jar is build navigate to the target folder and run the jar, like:
'java -jar spring-boot-ang-sample-service-1.0.jar'

Now, we can navigate to http://localhost:8080. Note that we can't navigate to 4200 and try to access the web app. In build, the whole web application runs in 8080 and web pages are accessible.
Also, the RESTFul API (endpoints) are accessible as usual at http://localhost:8080/api.

Now, let's hit the endpoint localhost:8080/api/time/local and we should see the same JSON as we saw above. Now, navigate to localhost:8080/, you should see the web page and hitting on the button hits the server and brings back the data and displays it. Note that all along we just use Angular HTTPClient to simply access the 'api/time/local' endpoint.

If you notice above, we built the UI project first and then the server project. This is because, in the build, we need the latest web distribution to be available at src/main/resources/static before the spring boot project is built.
Hence, if you notice the parent project pom, the module order is mentioned as UI coming first and then the services. So, when we run 'mvn clean install' on the parent project 'spring-boot-ang-sample', the UI project gets built first and then the service gets built. The final jar is present in the target folder of the service.

Also note that, the api is also accessible separately should you decide to use it to access from elsewhere like mobile apps. Thus, we have achieved the 4 goals mentioned.

Important: Also, note the files that have been ignored from git commit(s). Apart from the usual 'target' folder and IDE specific files, we have also ignored the 'src/main/resources/static' folder from commit. This is because, this has to be built fresh every time to reflect the latest UI changes, so, no one should commit these files to the repo.

The complete source code is available in my Github repo

References:
https://dzone.com/articles/building-a-web-app-using-spring-boot-angular-6-and
https://dzone.com/articles/simplified-building-web-application-using-spring-b
https://dzone.com/articles/angular-7-spring-boot-application-hello-world-exam

Spring WebSocket for Specific User Without Stomp

When I started to learn how to do web sockets with Spring, I was able to get lot of examples. However, almost all of them were using STOMP protocol. STOMP is important that it gives structure to web sockets. However, I still wanted to understand how the basic web socket works before moving on to STOMP.

In particular, this post will showcase an example web socket using Spring and sending messages to targeted logged-in user(s).

Most of the code for this example has been taken from http://www.devglan.com/spring-boot/spring-websocket-integration-example-without-stomp.
We add the targeted user messaging on top of this.

We first configure the Spring web security allowing users to login to the application using form login. We use in memory authentication with sample users for demo purposes. Plus, we use the standard technique by having an endpoint to get the login user (and on 401 it redirects to login).

Run the application as a Spring boot app and go to the url: http://localhost:8080/app.html. I have configured 2 users - user1/pass1 and user2/pass2. Login using one of these and click the connect button.

Once logged in, we have a landing page where we have a button which allows us to connect to the web socket (this would be done from plain Javascript and the script is put inside app.html itself). This script is simple, uses plain Javascript to connect to web socket. And, if a message is sent by the server to the connected client, we simply receive the message and add it to the '#greetings' div which is defined on the landing.html. The message is simply appended to the this div, so, we can see all the message as it is sent by the server.

On the server side, we use the Spring @EnableWebSocket annotation and register a web socket handler for the endpoint '/' (this is not usually the case, as a practice, people would have something like, 'directws' or something to indicate this separately - like we usually use the 'rest' for rest endpoints).

The web socket handler extends the Spring TextWebSocketHandler class and overrides the afterConnectionEstablished method. We create a BroadcastService and pass on the session. The BroadcastService stores the session in a list.

The scenario we have used is where a server needs to 'push' messages to connected clients (about a new event, or about an email which has arrived and so on). So, I have added a REST endpoint to help us to simulate this. I call it PushController which has endpoints like 'push/broadcast/message' which is for broadcast and 'push/targeted/{user}/{message}' which is for specific user. So, we can deploy the server and simulate the push by making a REST call to this endpoint from say Postman or ARC. These end points in turn call the methods of broadcast service that we talked about above.

Let's go back to the broadcast service and examine the methods. We have a broadcastMessage method which just loops over all the available web socket sessions (which was created when a client connected) and calls sendMessage on those - which will in turn sends this message to call connected clients. This is quite simple and works well for broadcast.

The other method is what we are interested about. The targetedMessage method takes the message as well as the user name - to which the message is targeted. So, now how do we send the message to the specific user?

The WebSocketSession class has a method getPrincipal which returns the principal i.e the user who has logged in. This actually returns the same old java.security.Principal instance - which is really cool as it neatly ties with the Principal object that we are acustomed to in Java Enterprise Applications. So, I now loop over the available web socket sessions and if the principal's name (user name) matches with that of user name passed into the method, we just call the sendMessage on that session - which ensures that the message is pushed only to the user.

The demo is not very efficient, but, I hope it conveys the basic idea. We can expand on this to other situations - like pushing messages to users of a specific role for example.

The complete code is available in my github repo.

Crores 2 Billion

I have been wanting to write a converter that can convert not just from crores to billions (and vice-versa), but, one with conversion rates. Plus also a way to easily mention large numbers like lakh crores or crore crores.

For example, I would like to know how much in million/billion $ would be Rs.1.76 lakh crore?

And, I finally developed and deployed the following app in the Google app engine:
http://crore-2-billion.appspot.com/

Important thing is that, I have used a simpler notation for the user to enter in large amounts.
The fields on the left hand side will be in Indian Rupees and the ones on the right will be in foreign currencies. The foreign currency can be selected in the combo (rhs). The left hand side has a conversion rate (which can be adjusted by the user).

So, if you want to convert 1.76 lakh crore, you can enter 1.76 LC - LC means Lakh Crore (case insensitive). Likewise, TC for Thousand crore and CC for Crore Crore and so on. So, you want to enter our budget numbers, you can do so with a simple notation.

When the right arrow (-->) is clicked, the Indian notation is converted into million/billion. We can see two fields on the right. One which just does numbered conversion and the other which includes the rate too.

So, when you enter 1.76 LC and click the arrow, you see this converted to pure number which is 1.76 trillion and also with $ conversion - which turns out to be $27.08 billion.

Likewise, you can do the reverse. Enter 165 M (for 165 million $) and press the left arrow key (<--).
It will be converted to lakh/crore along with the rate conversion and both numbers shown.

I hope this would be useful to finance people who track big budgets.

Spring Security Authentication and Authorization with Custom Schema

In my earlier post, I described how to do authentication and authorization with PicketLink using a custom schema. In this post, I use the same schema to perform the same with Spring Security and Spring Data JPA. Spring Security provides everything we need and we can configure authentication and authorization supported from a database using queries. In this post, I show an example of how to achieve the same using Spring Data JPA repositories.

Most of these are covered in the post: http://www.baeldung.com/spring-security-authentication-with-a-database.
I build on top of this by tweaking it to use the same schema as used in my earlier post where the password is kept in a separate table:

A simple one, with a table to store the user info, a separate related table to store password (this is useful because, when bringing back user from DB, we don't need to bring back the password related info). A master table for role and another table to associate the roles for a user.

I write corresponding JPA entities for these tables. Importantly, I don't have a relation from AppUser to UserPassword entity (it's the other way around) - simply because, as mentioned above, I don't want to bring back password information when I load user. Same applies in case of roles too. One of the basic concepts to remember about security is that, information should not be provided unless and until it is asked for (strictly on a need-to-know basis).

So, how do we encrypt the password and store the same in DB? Spring provides excellent support for encoders. So, we declare a bean in the config file, such as:

@Bean
public PasswordEncoder passwordEncoder() {
  return new BCryptPasswordEncoder();
}

Let us now look at how to create an user with password and associate a role. We can create the entities and persist with Spring Data JPA repository:

String role="ADMIN";

AppUser appUser = new AppUser();

appUser.setLoginName(email);

...

appUserRepository.save(appUser);

UserRole userRole = new UserRole();

userRole.setAppUser(appUser);

userRole.setRole(roleMasterRepository.findByName(role));

userRoleRepository.save(userRole);

UserPassword userPassword = new UserPassword();

userPassword.setAppUser(appUser);

userPassword.setPasswordHash(passwordEncoder.encode(password));

userPasswordRepository.save(userPassword);

The above block of code can be placed within a transaction and we can call this service from wherever user creation needs to be done.

For the user authentication to work, we need to wire a authentication provider which can be  a DaoAuthenticationProvider as we are storing the info in a database. We need to pass an service to this provider which implements org.springframework.security.core.userdetails.UserDetailsService. 

We also need to set the password encoder which is same as we saw above. The UserDetailsService is an interface, so we need to override the method loadUserByUsername() which should return a org.springframework.security.core.userdetails.UserDetails instance. 

So, we create a class which implements UserDetails interface. I have named this as UserLoginDto and I pass the AppUser object and the role of the user. Using this the overridden methods can return corresponding values. For example, the method isEnabled() can simply return appUser.isActive().

Most importantly, we have to override the getAuthorities() method which needs to return the list of roles assigned for the user. Since we have retrieved the roles for the user from the DB, we can use that to build the Set and return it 

(note: I have used only only role per user in this example, we can easily expand on that).

public class UserLoginDto implements UserDetails {

  public UserLoginDto(AppUser appUser, String passwordHash, AppRole appRole) {

    this.appUser = appUser;

    ...

   }

  @Override

  public Collection<? extends GrantedAuthority> getAuthorities() {

    Set<RoleGrantedAuthority> roleSet = new HashSet<>();

    roleSet.add(new RoleGrantedAuthority("ROLE_"+ appRole.toString()));

    return roleSet;

  }

  @Override

  public boolean isEnabled() {

    return appUser.isActive();

  }

  ...

}

So, when Spring is going to authenticate, it will call the loadUserByUsername on the service. We use Spring Data JPA repositories of AppUser, UserPassword and UserRole to fetch these values from the DB. We then build the UserLoginDto object and return it from the method. 

Note that, we need to fetch the password at this place as it is needed to authenticate the user. However, the AppUser object is free of this password and we can pass this around back to the UI separately. This should be enough for authentication. 

For URL based authorization, we can set it up in the security config,such as:

.antMatchers("/userpages/**").hasAnyRole(AppRole.USER.toString(), AppRole.ADMIN.toString())

.antMatchers("/adminpages/**").hasRole(AppRole.ADMIN.toString())

The complete source code for this post is available in my github repo.

PicketLink Authentication and Authorization with Custom Simple Schema

I was looking for a modern CDI enabled JEE security framework and found a very good one in PicketLink(PL) as it has pretty much everything. What's more, it combines with Apache DeltaSpike for authorization which is cool.

However, I have one or two problems asociated with PicketLink's IDM structure which we use for this:

a) The ID in the IDM User class is defined as a String and not an Integer/Long. This is a problem. In most cases that we encounter, the ID is a numeric type and is referred in several other tables. Being a numeric type comes in handy particularly when writing raw queries - which is needed when debugging production issues. The String in the IDM is also a generated one and results in a long hash - which is very difficult to track and use in these types of situations.

b) Secondly, how do I use PicketLink + DeltaSpike authorization with all its goodies to an existing database - which mostly has a numeric ID field?

c) Thirdly, could I have a much simpler table structure to deal with authentication and authorization? PicketLink's IDM is robust, but, we may not need it in all cases.

There have been some successful solutions used by other people. The most common is to have a numeric ID and tie it as an attribute in the IDM scheme of things and then refer to that numeric value in other places.

In this post, I use a custom solution which I found useful and simple - which might come in handy for small application(s).

I define a typical model for user management - which is not related to the IDM schems, such as:

A simple one, with a table to store the user info, a separate related table to store password (this is useful because, when bringing back user from DB, I don't need to bring back the password related info). A master table for role and another table to associate the roles for a user.

I write corresponding JPA entities for these tables. The numeric ID field becomes the primary key and is also auto-generated via a sequence. Importantly, I don't have a relation from AppUser to UserPassword entity (it's the other way around) - simply because, as mentioned above, I don't want to bring back password information when I load user. Same applies in case of roles too. One of the basic concepts to remember about security is that, information should not be provided unless and until it is asked for (strictly on a need-to-know basis). 

Let us first create sample users and roles. I use the @Initializer class (as it is done in many PL quickstarts). First, create the records for the 'role_master' and then create users with roles. For an user, this would insert 1 record into user table, 1 record into the password table and 1 into the 'user_role' table. 

First things first, how do we encrypt the password and store the same in DB? Had we been using PL IDM schema, the PL API would have taken care of the same. 

I do almost the same as what IDM does (benefits of open source!) - make use of the org.picketlink.idm.credential.encoder.SHAPasswordEncoder class to encrypt the password (and then use JPA to store the same). This class simply uses the java.security.MessageDigest class to get the SHA implementation (so, there is no big danger of depending on a PL implementation). We pass an argument of 512 to indicate the strength of the SHA algorithm.

(sidescript: the createUser method of the @Initializer class can be used to create user when you want to add user via the UI and this method can be placed in a transaction).

Now, how do we authenticate when the user wants to log-in to the application? We have the usual login.xhtml JSF page which is same as in any PL example. For authentication, as the default PL uses IDM, we cannot rely on that. We need to write our own authenticator and wire this up with the PL ecosystem. A nice example is given at https://github.com/jboss-developer/jboss-picketlink-quickstarts/tree/master/picketlink-authentication-jsf

I follow the same and write the CustomAuthenticator class. Instead of IDM schema, I use simple JPA queries to query the user and the password tables with the user entered user id and password. As the user id is the login name in my example, I use the findByLoginName query to check against the user table (note that the numeric id that we spoke about in the beginning is obviously not used as the login id by the real users). 

As for the password, we again use org.picketlink.idm.credential.encoder.SHAPasswordEncoder instance and call the verify method after we get back the password hash from the table using JPA. 

Now comes the most important part. If the authentication is successful, we set the status as AuthenticationStatus.SUCCESS. Once we set the status as success and the page is loaded, the identity.isLoggedin would be true and the user and admin links would be displayed.

And next, we have to set the account object. This account object should be a type of org.picketlink.idm.model.basic.Account. This is in a way enforced by the API. Setting this account is both important and useful as this is the account that is retrieved via the Identity object (which can be injected). This is same as setting the user info in the session.

Now, because we are forced to use the IDM Account object (as the setAccount method takes that type), we will create an instance of org.picketlink.idm.model.basic.User class - as User extends Account. Now, we have to set the values of the User object (fn, ln, email etc.). The most important information is the ID. As outlined earlier, the ID within this IDM User object is a String. The ID that we use in our AppUser is a Long. So, we simply convert the Long to String and set it into the User's ID. 

So, now, later on, wherever we need the ID, we can simply @Inject the Identity object and get the value. For example, to get the user name, we can do:
((User)identity.getAccount()).getLoginName()

Now, to the next important part - authorization:

Authorization checks would be needed at two levels. One is at the UI side and the other at method-level checks on the server-side. Apache DeltaSpike provides a CDI enabled authorization module which blends nicely with PL. Some examples can be found in the PL quickstarts for the same.

We are going to deal with the UI side authorization checks - this again would be needed at two levels. First is at the displayed UI, where a part of the UI is hidden/disabled for certain roles. Second, at the URL level.

Within the UI, there are a few types of authorization needs. One is that showing/hiding or enabling/disabling parts of the UI for specific roles. Let's see how this works. This is actually very simple. Login as 'user1' and goto the common page - you should see the 'Save' button in disabled state. Now, login as 'admin1' and goto the common page. Now, you should see the 'Save' button enabled. 

This is achieved simply using JSF EL. The JSF EL uses a named bean 'authChecker' (AuthorizationChecker.java) on the isAdmin method. The isAdmin method in turn queries the 'UserRole' table using a JPA query to check if the user has the specified role. 

This is cool. Likewise, you can navigate to the admin page. The link to the admin page (menu) shown on the home page can also be shown/hidden based on the role. But, what if the user copies the admin url and pastes it into the address bar after being logged in as a normal user 'user1'? So, we need URL level authorization to happen here.

PL does supports URL level authorization in a simple manner. However, there are some issues here. Since our whole model is customized and not based on IDM, the custom authorization of URLs for a specific role does not work. For example, the following does not work:

When we build the security configuration, we can make use of the forPath() and authorizeWith() methods to specify URL authorizations. For example, we use the following in our code:

  .forPath("/faces/admin/*")

  .authorizeWith().role(AppRole.ADMIN.toString())

But, how and where do we hook the role into PL? Remember that in the custom authenticator that we wrote, we set the status and the account. But, nowhere did we set the roles for the logged in user. And, there is no method on the PL Account class to set the roles for the user.

This is usually the norm. Roles are not set anywhere. Security works on a need-to-know and deny-first principles and so the hasRole and such methods are provided. Still, we need to figure out on how this will work.

We can write a custom authorizer for URL level authorization too as follows:
.forPath("/faces/admin/*")
.authorizeWith().role(AppRole.ADMIN.toString()).authorizer(CustomPathAuthorizer.class)

This class needs to override the authorize method and return true/false. So, we can write our custom auth checks inside this method and return the value accordingly.This method takes a PathConfiguration as a parameter and we can get the roles with the following call:

pc.getAuthorizationConfiguration().getAllowedRoles();

And then with that, we can do our custom auth check. More info can be found from org.picketlink.authorization.DefaultAuthorizationManager source.

However, when I implement this and run, no matter what role I am logged on to, going to the admin URL directly simply fails and I get a 401/403. I began wondering if this was a bug and posted in the forum (https://developer.jboss.org/thread/272838)

Let's take a step back and see how the default PL works first. There are 4 authorizers built by default and added which are called one by one to do the check (authorize method which returns a boolean). If any of them return false, authorization will be denied.

When we add the custom authorizer, even though it is added as a 5th one, it seems, one of the default 4 returns false and so we continue to get access denied. And all the default authorizers are tied to the IDM schema.

I found a workaround thanks to a tip in one of the forum messages. The tip was to not use the 'role()' method at all. So, I tried that and the authorizer is working fine with the same now. Just use:
.authorizeWith().authorizer(CustomPathAuthorizer.class)

So, where do I specify the roles for the URL? Inside the authorizer, I can get the pathInfo from the request and then use it to check with my roles. For example, in the authorize method, I can get the path and then check against a List/Map to verify if this path is allowed for the role of the logged in user. As an example, I have used a trivial sample map with path and list of roles. For more robust ones, we can propably have this data also in the database.

In the current sample, I just loop against the paths to match and then see if the logged-in user has the requisite role to go to the URL. To test this, login as a user and then paste the admin URL directly in the browser. You should see an access denied page.

The complete sample code is available in my github repo.