UrbanCode Deploy security: roles, teams, types, permissions

In my last post I covered using Microsoft Active Directory as an LDAP provider for Urbancode Deploy (UCD). At the end of that process the new users I had added couldn’t do anything except log in. To allow those users to be productive we need to configure the teams, roles, types (if needed) and permissions. I also wrote that I had to read the Infocenter topic a few times and work through some examples to get the hang of how these concepts relate and are used.

Matt Wagner (Lead Developer, IBM Urbancode Deploy) has an excellent, concise video – Configure Security in IBM UrbanCode Deploy v6.0 – that goes through the security model and explains each of the concepts. He also has a short demo that shows how to implement an example scenario. I probably can’t do better than Matt so I won’t try:-)  Here’s a quick and dirty summary of the steps he goes through, with links to the relevant topics in the Infocenter .

1. Setup authorization and authentication Realms

2. Create new security types if needed. This can also be done as part of the next step

3. Define roles and grant permissions to role member on an object by object basis

4. Define teams and add users/groups to Teams

6. Associate individual objects (applications, environments, components etc.)   to teams and types

There are also a few points in Matt’s video that are worth highlighting:

1. UCD’s security model is extremely flexible and it doesn’t all have to be laid out before everything else ie. it can be progressively implemented. However as Matt points out, it’s worth spending some effort in the early stages of a deployment automation implementation to have some idea of what the organization’s expectations are with regard to security of applications, components, environments etc. It’s also important to keep in mind that a security implementation for a primarily manual deployment process is likely to be more complex than one that takes advantage of the built-in security features in a deployment automation framework such as UCD.

2. The term “Role” is slightly overloaded. In one sense it refers to the set of permissions provided to users belonging to a role such as “Developer”, “Product Administrator”. In another sense, when associating objects to teams and security types, it refers to the security type assigned to an object. For example in Matt’s video the PROD environment for the BankingApp is assigned the Production “role” which means it is being assigned the Production security type.

envrole

3. Make sure that Web UI permissions are granted to roles. Else they won’t be able to see the objects they have permissions on.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s