uc.png Security

Authors: StevenBeard, TimFeeney
Build basis: CLM

Page contents

Security Facilities

The Jazz Team Server application is packaged as a Java Enterprise Edition (Java EE) Web Application and as such runs in a supported Java EE container using a standard authentication, authorization, and permission model. The application also uses a set of predefined roles that are assigned to users, for authorization to access specific URLs or to perform specific low-level operations (e.g. read, write, administer). The "container" is another term for "application server", e.g. IBM WebSphere Application Server (WAS) or Apache Tomcat. The authentication itself is managed by the container; if a user fails to authenticate by providing a valid user id and password, then the container rejects the request without the request ever reaching the application. When the user successfully authenticates, the container subsequently forwards the successfully authenticated request to the application (Jazz Team Server in this case) along with the current user's authorization ( Group Memberships or Role) for processing. Within the operation that processes the request, the application first checks that the user is assigned a role with requisite authority to perform the operation.

The configuration of the authentication and authorization is done at the container level, at login time the application server retrieves the user information from the external user directory. Apache Tomcat Realm and Lightweight Directory Access Protocol (LDAP) are external user registries supported by the Jazz Team Server application. To support authorization, the group membership of the users must be managed in the user registry. LDAP may be used with both Apache Tomcat and WAS. Jazz Team Server authentication is further explained in Tech Note TN0013. Finally, in RTC 3.0, support for Common Access Card (CAC) Smart Card and generic certificate based authentication is provided, more information available in Configuring certificate authentication in Rational Team Concert 3.0 using WebSphere Application Server 7.0.

Once a user is authenticated and authorized to access the Jazz repository, the application, e.g., Team Concert, performs process-level authorization based on a user's role and what permissions and operation behaviors have been allowed for that role. Roles identify the functions of team members and can be defined at the project level or within a team area. Permissions are then assigned for specific operations to roles at the project level or within a team area. A user may be assigned more than one role. Behaviors define preconditions and follow-up actions for individual operations. This behavior encourages or enforces process rules for your project and your teams. Behavior is defined in the project's process configuration and can be customized by team areas. For a demonstration of permissions in the Team Concert application, see this video. Permissions and behaviors as described here is the general Jazz model, however, how it is implemented and exposed to the user varies between the applications.

New to Collaborative Lifecycle Management (CLM) 2012 are a few additional security features at the individual product levels to support finer read and write controls of project artifacts. Rational Requirements Composer adds support for additional fine-grained write access controls for artifacts and folders by Project and Team for controlling write access to shared resources. Rational Team Concert extends the component and stream level scoping adding support for global folder level security within SCM to public, private, and scoped. Rational Quality Manager adds support for finer grained access control within Project Area and Team Areas.

Licensing also impacts the security model and whether an authenticated user is able to perform actions they are authorized to do. The licensing model used in CLM 2012 is the same as described in Licensing in the Rational solution for Collaborative Lifecycle Management (CLM) 2011.

For Jazz products to interact with each other, each server must add the other server to its list of friends. Further, application project areas must be linked together to enable artifact linking. In CLM 2012, this friend configuration is handled automatically through the post-installation setup wizard and creation of lifecycle projects.

Related topics: Deployment planning and design

External links:

  • None

Additional contributors: None

This topic: Deployment > WebHome > DeploymentPlanningAndDesign > JTSAuthenticationExplained
History: r9 - 2013-06-03 - 19:18:59 - MichelleDeArmas
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use. Please read the following disclaimer.
Ideas, requests, problems regarding the Deployment wiki? Create a new task in the RTC Deployment wiki project