Architecting Cloud Application for the Enterprise – Part V – Management

Having solved the identity issue, the SuperCloudySoftware team focuses then on the management requirements raised in the meeting with VeryBigCorp CIO.

To recap, they want to:

1. Be able to to monitor IssueTracker from their existing infrastructure, that happens to be System Center Operations Manager (SCOM) and eventually author new rules to correlate IssueTracker specific events with other events that are generated inside their boundaries.
2. Be able to logically disable and enable IssueTracker for users from SCOM and
3. Be able to change claim mappings for authorization purposes from within standard tools (e.g. they don’t want to use a new web portal but would be happy with an MMC Snap-In)
4. As with their other (business) users, they want seamless integration for their IT staff: no login, no pop-up, etc. If an authenticated user of their network is authorized to do monitoring, he /she should be able to do it without any additional checks.

John and his team realize that the Web dashboard for monitoring is not enough for these requirements. It is still a good thing for their smaller Customers that don’t care too much about it anyway except when there are problems, but it will not work for VeryBigCorp.

The team realizes that they need to do a couple of things:

1. Instrument the application to gather information and to provide some level of control (e.g. enable/disable)
2. Create an external API for management
3. Create common clients for that API (e.g. PowerShell CmdLets, SCOM Management pack, etc)

Of course securing the API is relatively easy now that they have a claims based architecture as described in the previous post and can federate with consumers. They can leverage the same rules for granting access to this API: for example, VeryBigCorp would just need to define what claims will be mapped to the “Enable Application” claim that IssueTracker will expect.

The high level solution is illustrated below:

To simplify things even further, SuperCloudySoftware pre-configures the client library and the clients. So, just after provisioning, a client library will be automatically generated for the Customer with all the necessary information: more specifically, the information to setup WS-TRUST between IssueTracker, Access Control Service and the company (STS address, certificate, etc):

VeryBigCorp IT staff can then download the (pre-configured) tools from IssueTracker web site and they will “just work” as long as the logged in user provides the right credentials:

Notice there’s no need to specify who the tenant is, where the IssueTracker Management endpoint is, etc. All of that is built into the client library that the CmdLet uses.

SuperCloudySoftware strategy is to supply 3 experiences: MMC, PowerShell CmdLets and a SCOM Management Pack, but if there’s a customer with special needs (e.g. they are using Tivoli or HP OpenView), they also provide an API (secured with WS-TRUST).

Next article we will dive deeper into some implementation details of both the security and management aspects. As mentioned before, all of these is available in the download here.