In that case, the application still delegates OAuth 1.0a authentication to a Jazz Team Server (more on that below).įigure 2: Jazz Security Architecture Single Sign-On Kerberos When Jazz Security Architecture SSO is enabled in an application that would normally delegate authentication to a Jazz Team Server, then the application will instead delegate to the Jazz Authorization Server using OIDC, unless the incoming request uses the OAuth 1.0a protocol.
This option became available in the 6.0 software release, which includes the Jazz Authorization Server, an OP that supports the Jazz Security Architecture profile. Single sign-on is supported across all applications that are configured to use the same OP. Authentication is handled by a separate OpenID provider (OP, also known as an authorization server) Jazz applications delegate to that provider instead of relying on the application server to handle authentication. Jazz Security Architecture is a particular profile of OIDC, specifying which optional features are included, and a few extensions. It is extensible and configurable (with optional features). The OpenID Connect (OIDC) authentication protocol was established in early 2015 as an extension of the OAuth 2.0 protocol, designed to be easier to adopt across a wide range of clients (native applications, browsers, browser-based applications, and mobile devices). When applications are deployed in separate application servers, by default users must login to each of them, though WebSphere servers can be configured to implement single sign-on across a collection of servers.įigure 1: Container Managed Authentication Jazz Security Architecture Single Sign-On (SSO) based on OpenID Connect Of the four types of login allowed by the Java EE servlet specification, Jazz supports three of them: form (the default), Basic, and client certificates. This is the default configuration, and is the only configuration supported in releases prior to 6.0.
All other applications delegate authentication to the Jazz Team Server (by redirecting clients to the Jazz Team Server to authenticate with it). The “web container”, or application server (WebSphere or Tomcat), handles authentication for the Jazz Team Server, Rational Team Concert, and Rational Quality Manager servers. There are three options available for configuring user authentication in Jazz products. More Information Authentication Mechanisms
It also describes how to change the configuration to use alternate authentication methods and how to unsecure feed URLs for a custom deployment, along with the tradeoffs associated with each configuration. This note explains the authentication mechanisms used by Jazz applications, and reasons for choosing one over the other.
The 6.0 software release adds two new authentication options, Jazz Security Architecture based on OpenID Connect, and Kerberos. By default, the “core” applications (Jazz Team Server, Rational Team Concert, and Rational Quality Manager) use Java EE authentication per the Java Servlet specification, and the other applications (for example, Rational Doors Next Generation) delegate authentication to a Jazz Team Server. Jazz applications that are included with Collaborative Lifecycle Management (CLM) or Systems and Software Engineering (SSE) are deployed as Java Enterprise Edition (Java EE) Web Applications, and as such run within a supported Java EE application server (IBM WebSphere Application Server or Apache Tomcat).