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.
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.
Domain-level security is disabled by default. As an administrator, go into the Administration > Security tab of Rational Test Control Panel and enable it.
Once enabled, any user that is not specifically added to a domain will not have access to anything in that domain.
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.
Now that user will see any available domains in the domain selection box at the upper-right of RTCP.
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:
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.
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.
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.
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.
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:
You can further restrict a proxy or agent’s access to only given environments 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.