ALF/architecture/ALF Security and SSON
- 1 Introduction
- 1.1 The focus of this document
- 1.2 Statement of the Problem
- 1.3 The phasing of single sign-on and other ALF security aspects
- 1.4 Scenarios / Use Cases for SSO
- 1.5 Overview of ALF Approach for Authentication/SSO
- 1.6 Essential choices and characteristics of the ALF SSO approach
- 2 Related Resources
As a platform for tool integration, the Eclipse Application Lifecycle Framework (ALF) project provides the foundation of “plumbing” and “process” to allow tools to communicate. That plumbing consists of conventions and implementation for event handling, process orchestration, data mapping, and message exchange.
On top of that foundation, ALF also needs to convey among the participating tools information about who is making a web service request, or on who’s behalf a web service message is being sent, since most tools have a requirement for authentication – that is, knowing who is operating (or at least invoking) the tool. Single sign-on (SSO) extends the notion of authorization by only asking the user to authenticate once, and then reusing that authentication result as the user’s request traverses other tools that may be invoked in the process of executing a ServiceFlow.
One unique aspect of ALF is that the many of the tools invoked via ServiceFlow are invoked via web services, not directly by the user, so modifications to the standard single sign-on approach (which were designed for a user at a browser invoking multiple tools) need to be made. Fortunately, the WS-Security framework provides the mechanisms for extending the notion of single sign-on to the world of web services.
The focus of this document
This document you are reading describes the “big picture” of ALF Single sign-on, independent of particular implementation technologies. This document covers:
- Background and Motivation
- Implementation Phasing
- Applicable standards
- Threat Assessment
- ALF Security Architecture
A separate document, ALF Security Technology and Design: Single Sign-on (SSO) will cover how to convert that architecture into an implemented reality. That document will cover:
- Available implementation technologies – what open source implementations can ALF draw from
- Modifications or extensions that will be required to those open source components
- Technical design – what design decision are made (or need to be made), how we will assemble the pieces, what the actual interfaces will be, etc
Statement of the Problem
ALF facilitates the coordination and interoperability of development tools. A user using one tool may make a change that triggers a ServiceFlow (i.e., a BPEL process orchestration) that invokes a number of other tools. Since the tools communicate via web services, the challenge is to:
- Communicate the fact that the original user had authenticated at the tool he was using to the other tools that are invoked as a result of the resulting Service Flow.
Said another way, we want ALF to enable “single sign-on”. That is, the ability for a user to authenticate once to the first tool he works with, and not pester him again to authenticate to each tool that is subsequently invoked as part of the ALF coordination process.
If we break that down, there are a number of smaller problems to solve:
- Have the user authenticate to that first tool such that the fact of his authorization can be reused by the other tools. We will refer to that “fact of his authorization” as an authorization token.
- The authorization token itself should be secure in the sense of not allowing it to be viewed such that it could be reused by someone attempting to “spoof” the original user.
- Specify the mechanism for communicating that authorization token from the original tool, through the ALF Event Manager, through the Service Flow (BPEL) engine, and finally to the tools invoked as part of the Service orchestration.
- Have those secondary tools that run as part of the service flow accept that authorization token as legitimate proof that the web service request they received should be honored (as if the original user had directly logged in to that secondary tool)
Now, there are variations on the theme (such as options for substituting other system ids for the original users, or dealing with the authorization aspects) but those 4 bullets, above, are the essence for single signon.
This document describes the approach and architecture for providing single sign-on for tools that participate in the ALF environment.
The phasing of single sign-on and other ALF security aspects
For practical reasons, ALF will address the key aspect, authentication, first, in the ALF 1.0 release.
Authentication (Single sign-on)
ALF 1.0 will support user authentication and single-sign-on, as described, above. Authentication means verifying a user is who he says he is, and single sign-on lets that authentication occur once and share it among other tools.
With single sign-on for a web service environment, the goal is to shift the complexity and burden of authentication from individual tools to an Authorization Server (also called an Identity Server or Identity Authority). Several Authorization Servers may exist, for example, one per domain.
Sometime following the ALF 1.0 release, ALF will add the notion of authorization – that is, specifying what operations a user can perform. This work can be divided into two aspects:
- Authorization at the Service-Flow level – That is, allowing an ALF Administrator to specify which ServiceFlows a given user may cause to be invoked. The ALF Event Manager is the enforcement point to control who can invoke. ALF will provide this level of authorization, though possibly sometime after ALF 1.0 is released.
- Authorization of operations within a tool – That is allowing a tool administrator to specify which operations within a tool a given user is allowed to perform. ALF may never provide this tool-level finegrained level of uniform authorization for the following reasons:
- Most tools already provide their own proprietary mechanism for authorizing users to operations within themselves
- The nature of the privileges (or entitlements) varies considerably from tool to tool
- The nature of the permission granting mechanism varies considerably. Some tools only allow positive GRANTS; others include negative DENIALS of performing an operation.
- The decision making and enforcement of privileges within a tool can be intimately embedded within a tool at a point in the code were the cost of contacting an external authorizing authority would be prohibitive.
What may be possible to achieve is to define a common authorization format that get mapped (translated) into the authorization language of each tool,. But that discussion is outside the scope of this document.
It should be noted that the solution to achieve single sign-on will establish some of the machinery needed to support authorization, So SSO will provide a boost to authorization, but that additional machinery will need to be added to achieve an authorization capability.
Message privacy and protection from tampering
Depending on the configuration and location of tools running in an ALF environment, some messages between tools or between ServiceFlows and tools may be transmitted over non-secure networks. Two aspects of security are needed: message privacy (so the message contents cannot be viewed by unauthorized eyes) and message integrity (so the message contents cannot be tampered with without being detected. Privacy is usually provided by encrypting the message (or parts of it); integrity is usually provided by signing the message with a secure hash or checksum.
There is a fair amount of good news in this area:
• First, as with all security situations, there is no such thing as absolute security. Each threat and its consequences must be evaluated and weighed against the cost of eliminating that threat. The risks and consequences involved with software development are much less than those for financial, medical, safety, military, or national security applications. The risks of tampering or the consequences of someone spying on, say, the datatype of a field on a screen, are fairly low.
• Second, there already exists well-established, proven standards for ensuring both the privacy and integrity of the web service messages use by ALF. The WS-Security standard defines how to provide both privacy and integrity using SOAP, XML Encryption, and XML Digital Signature.
ALF 1.0 will put the foundation in place by making use of WS-Security to secure the authentication information, but will not provide explicit support for encrypting and signing other parts of the message. This is due to the extra development effort involved when compared with the relatively low risk involved. Subsequent releases of ALF will have all the machinery in place to add this capability later.
Audit and Non-repudiation
ALF 1.0 will provide a logging mechanism that can form the basis of a security logging capability. But the amount of information logged will be at the discretion of the ALF Administrator at each ALF installation, and ALF will provide no tools specifically designed to analyze ALF log files for security violations. At least for ALF 1.0, that will be left to the users. Expanding on this, the ALF log files may be used as a basis for nonrepudiation, but for reasons that the cost outweighs the need (e.g., how often does it occur that a developer denies he made a change to some code, or entered a bug request). So, no tools explicitly for non repudiation will be provided by ALF 1.0, though all the log files will be in place to allow users of ALF to build their own capability, if warranted.
Scenarios / Use Cases for SSO
There are three use cases for ALF SSO:
1. Conveying credentials from a tool initiating an event to all programs invoked from the resulting ServiceFlow. This is the critical use case for ALF, since without that capability, ALF will not work in the ideally secure manner desired in most development shops. This will be the primary focus of this document. But to be pragmatic, the ideal exceeds the reality in many shops. And ALF is intended to provide useful functionality even where tools do not support web services security. So the design for ALF SSO promotes the conveyance of security information throughout a ServiceFlow, but also accommodates those tools that are not prepared to handle web services security and were shops can accept that reduced level of security.
2. Allowing an end user to authenticate at one web-based tool and then use a second web-based tool without reauthenticating. While this has been the traditional model for web single sign-on, it is the less critical for ALF, as it is more of a convenience issue than the first use case. Existing browserbased SSO approaches, such as Yale’s CAS and Shibboleth exist that address this use case. ALF SSO will address this use case, with a blend of existing approaches with ALF SSO.
3. Allowing an end user of a desktop based tool (such as Eclipse-based tool) to obtain credentials from the operating system on the user’s workstation, such that those credentials could be exchanged for an ALF Security Token.
Overview of ALF Approach for Authentication/SSO
Guidelines and considerations which impact the ALF SSO approach
ALF support for authentication and single sign-on has the following guidelines and considerations:
- ALF will deliberately not attempt to invent a new way of achieving single sign-on. Rather, ALF will leverage industry standards, such as the WS-Security family of specifications, the Security Assertion Markup Language (SAML), XML Encryption, XML Digital Signature, etc.
- ALF will allow the ALF Administrator for each ALF environment to determine how secure ALF is. Stated more precisely, the ALF administrators at user sites will determine the security threats, risks and consequences of those threats, and the cost of implementing countermeasures. As described, earlier, over time and subsequent releases of ALF, ALF will provide additional “levers” to control the various aspects of security. For ALF 1.0, the focus will be on authentication and single sign-on.
- ALF will attempt to write the minimum amount of new code to implement security. Instead, ALF will leverage existing relevant open source implementations to the greatest extent possible, and only write the minimum amount of code to “tie the pieces together”
- Tools will need to make changes to participate in ALF, such as no longer relying on having a users password available, but the pain of such changes will be mitigated by:
- Choosing the approach to be aligned with the direction that tool vendors would like to go even if ALF was not in the picture. That is, most tools were built before web services and federated identity were a reality, and before tool end-users demanded tool integration and single-sign on as strongly as they do today. By choosing as natural (and non-proprietary)approach as possible, the goal will be that ALF Security will “pull” vendors in the direction they would like to have gone anyway. ALF will simply make it easier by providing a tested approach and infrastructure.
- Minimizing the vendors’ pain by providing sample code.
- Being sensitive to the fact that vendor tools have existing customer bases. And that those customers resist change unless compelling counterbalancing benefits (such as single sign on) are provided.
- Standard approaches for implementing authorization in a flexible manner, such as the use of Pluggable Authentication Modules (PAM), will be promoted.
Essential choices and characteristics of the ALF SSO approach
ALF support for authentication and single sign-on will involve the following (which parallel the points in the “Statement of the Problem: section, above):
• Tools users interact with and can trigger ALF events are the users first “point of entry” into ALF. As such that “point of entry” tool will interact with an ALF Identity Server to authenticate the user and establish an authorization token that can be communicated through the Event Manager and ServiceFlows to secondary tools.
• WS-Security (WSS) will be used to communicate the authentication token on the Web Services messages exchanged by the participating components of ALF. That is, WSS defines the elements and formats for placing and securing the authorization token in the SOAP header of ALF messages (including Events).
• The Security Assertion Markup Language (SAML) will be used to represent the authorization token information for ALF 1.0. SAML Tokens will be signed by the issuing authority (the ALF STS). Certain fields within the token will be encrypted by the ALF STS to prevent the forging of unauthorized ALF Security Tokens.
• The Event Manager will communicate the authentication token from the initiating tool through to the Service Flow. In addition, the Event Manager will pass through the Event Context information provided by the tool that emitted the event.
• The author of the ServiceFlow is responsible to ensure the Authorization token (or alternate token) is passed to each and every tool invoked via web services in the course of executing a ServiceFlow. ServiceFlows will similarly convey and properly process the Event Context information that is passed into the ServiceFlow from the Event Manager. [It is the hope that after ALF 1.0, ALF design tools will assist in ensuring this occurs (either by checking or enforcing).]
• Tools that receive web service messages from a ServiceFlow will extract the Authorization Token, and then take one of two courses of action:
o Make a web service call to the ALF Identity Server to validate it. The tool will accept the determination of the ALF Identity Server as to whether or not the token is valid.
o Use the information provided in the Authorization Token to validate the token itself. This will require that the issuer of the Authentication Token signed it.
If the token is valid, the tool may make a subsequent query for some basic user identification information (e.g. one or more USERIDs) , though in no case will the tool be allowed to access the password or other information the original user provided to authenticate.] Such userid information is frequently required for tools to determine what operations the user is authorized to perform.
• ALF will not take the approach of synchronizing ids and passwords among the various tool stores that have historically held userid, password, and entitlement information. Instead, the ALF Identity Server will perform any mapping of ids as required by a given tool.
• The ALF Identity Server will not provide the primary source of identity information. At most ALF user shops, existing directories (such as LDAP-accessible directories) have been adopted and in some, commercial security packages will have been adopted. The ALF Identity Server will simply be a unifying façade, or intermediary on top of those existing directories of user information.
• Separation of concerns: To accommodate layered application architectures in which <soap:Header> element processing is segregated from the application processing of the <soap:Body>, some user identification information (such as the userid) will be duplicated in both areas. However, credentials information will only travel in the <wsse:Security> element of the <soap:Header>