Domains, Environment and Projects – Administration

This is a follow-up to my previous post Domains, Environments and Projects – making sense of it all.

Now that we understand the purpose of Domains and their related artifacts in the Rational Test Control Panel, let’s take a look at how we can make use of them.

Visibility

Again, as described in the KnowledgeCenter, A domain represents a logical grouping of related systems that are part of a real business project and it is the basic unit of management within IBM Rational Test Virtualization Server.  In the last post, I mapped each organizational division to a domain.  This will enable JKE to organize which stubs are published and visible in which domains.  That will help us make only relevant stubs visible to the various teams.

Security Access

Domain-level security is disabled by default.  As an administrator, go into the Administration > Security tab of Rational Test Control Panel and enable it.

Enable Domain-level security

Enable Domain-level security

Once enabled, any user that is not specifically added to a domain will not have access to anything in that domain.

No domains for unauthorized user

No domains for unauthorized user

Users are added to domains in the Administration > Domains and environments area by selecting the domain and then the Users sub-menu and clicking the green add icon.  Users can be given three levels of access: Domain administrator, User and API User.

Add a user to a domain

Add a user to a domain

Now that user will see any available domains in the domain selection box at the upper-right of RTCP.

Domains available to a user appear in the domain selection list

Domains available to a user appear in the domain selection list

With this in place, you not only provide visibility constraints, but also access constraints.  But, access constraints apply not only to users, but to proxies and agents as well.  Since we have not yet configured any proxies or agents for domain-level security, they cannot register to domains or environments within those domains.  If our domain user looks at the Environments tab (was VIE tab prior to v8.6), he will see this message:

No agents registered for this domain

No agents registered for this environment

This brings us to our third use for domains – controlling access to services.

Proxy/Agent access control

Proxy and Agent access control is implemented with security tokens.  An administrator creates a security token which is used by the proxy or agent to authenticate to RTCP.  The security token’s permissions determine which domains the proxy or agent can register with.  The security token is associated to a user when it is created.  The proxy or agent therefore gets the access of the user who corresponds to the security token being presented.

As an administrator user, create a token in the Administration > Security tab.  Select the user to which the security token will be bound and enter a description for the token.

Create user security token

Create user security token

Now provide the security token to the proxy or agent configuration settings.  For proxies, this is done by pasting the security token string into the security-token attribute of the server element of the registration.xml file for the proxy.

Adding the security token to the proxy registration.xml file

Adding the security token to the proxy registration.xml file

For agents, this is done by pasting the security token string into the security-token attribute of the rtcpURL element of the Agent.config file for the agent.

Adding the security token to the Agent.config file

Adding the security token to the Agent.config file

Restart any proxies or agents you have modified.  The proxies and agents started using this security token will be visible in all domains and environments, but they can only be used in domains where the user associated with the security key has permissions to work.

Proxy/Agent visibility

A proxy or agent’s visibility can be restricted as well.  This is done by the domains element in the proxy’s registration.xml or the agent’s Agent.config file.  For example, to cause my proxy and agent to only be visible to the Mobile Banking domain, I would add the following:

Restricting proxies or stubs to a specific domain

Restricting proxies or stubs to a specific domain

You can further restrict a proxy or agent’s access to only given environments within a domain.

Restricting proxies or stubs to a specific environment within a domain

Restricting proxies or stubs to a specific environment within a domain

Wrapping it all up

Now this becomes really powerful.  So consider again our multiple JKE teams all trying to build client applications that leverage the same payment calculator service.  Each team wants to use a stub for the payment calculator service, but they each want their own variant of that service.  The domain architecture of Rational Test Control Panel and the
ability to control which domains the proxies and agents can register into would enable each team to have their own personal proxy/agent pair visible only in their domain.  The members of each team would have permissions to their own domain.  Each team would publish and run their own Payments Calculator stub to their own domain.  Now, without changing the endpoints of any of the client applications, each team’s proxy will route requests from their client to their stub.  There are all sorts of options where multiple domains could share proxies and agents, thereby enabling them to use a common stub.  This could be part of a strategy to use incremental integration testing at an enterprise level.

Domains with separate and shared proxies

Domains with separate and shared proxies

Advertisements

3 thoughts on “Domains, Environment and Projects – Administration

  1. The “API user” role is useful if you have a user account specifically for the agents and the proxies. Then you can generate tokens using that account, and you know that those tokens have the lowest level of permissions (which is enough for the agents and proxies).

    Also, the “description” field of the generated tokens is useful for saying which components you intend to use that token. If you generate a separate token for each use (i.e. for each proxy, agent, ant script, and command-line script using the RTCP APIs) then you can revoke (delete) each token independently when needed.

    These two things together allow fine-grained control (if you want it) of the non-UI access to RTCP, when domain security is enabled.

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