The previous article explained how we made an existing enterprise application available as a service in a CF environment. This article explains how we have transformed this application as a Cloud Foundry service. This article is associated to a demo application.
The existing application offers a web-service API secured by a basic authentication mechanism. That API will be exposed as Cloud Foundry service. The application is also composed of a set of UI web-pages allowing to administrate the API. Those pages are secured by a form-based authentication. They will become the Cloud Foundry dashboard.
The development mainly consisted to integrate OAuth. In order to ease its integration we have introduced Spring Security. In a first step, we simply migrate to Spring Security keeping the same features as before: basic authentication for web services and a form-based authentication for the UI. In a second step, we have replaced the form authentication to an SSO authentication via OAuth2 interacting with Cloud Foundry. In this environment, all the OAuth2 (dashboard) users are defined in the Cloud Foundry environment. Users are added/updated/removed thanks the Cloud Foundry command line.
The following screenshot shows the login page for OAuth2. This page comes out-of-the-box with Cloud Foundry community.
The OAuth integration can be achieved without having the whole Cloud Foundry infrastructure. We initially started the integration with a standalone OAuth server (Cloud Foundry UAA). Once we had a Cloud Foundry infrastructure we use the real UAA. Switching to the real instance is only a matter of configuration (some properties to change). The demo application contains the Spring security configuration we used.
The other part of the security migration was the implementation of an authorization mechanism. Indeed, the dashboard is responsible of checking that the current user (logged via OAuth) can access the current dashboard instance. Every provisioned service has its own service dashboard instance. Users associated to a service instance cannot see the dashboard of a provisioned service that they cannot manage. The authorization mechanism simply performs a REST call to the Cloud Foundry Controller. The controller returns a boolean indicating whether the current user is allowed to access the specified service instance id.
In the same way than we use a standalone UAA that does not require an up-and-running Cloud Foundry instance, we used a standalone Cloud Foundry Controller. In this case we developped an home-made stub controller. This controller is only intended for tests purpose and only for this particular check. Again, migrating to the real Cloud Controller was a matter of configuration.
The following sequence diagram illustrates the whole security mechanism:
The dashboard must know its associated service instance id. We chose the following solution: when our service broker provisions the service it calls a web service with its service instance id. The web service write the id in a file accessible during the whole life of the service (the demo does not contain the web-service). The web service is secured with a default user and a default password. Those credentials are shared by every service instances and the broker, but they are never transmitted to service clients, neither to users. The way we provide the service instance is the easiest way, but it means we could provision a service instance only once. In another service, we choosed to specify the service instance id in the dashboard URL.
Finally, we have customized the application. The application exposes some business web services and at the same time it acts as a Cloud Foundry dashboard via UI web screens. We have reduced those screens only to a sub-set that makes sense for the business web services it exposes. OAuth users (defined in Cloud Foundry) are automatically mapped to users of our application. Those users are allowed to manage managment screens.