Keywords: XACML, SAML, Web Services
Biography
John is a software engineer who has been a successful engineer, architect, and leader within technology companies both in the UK and US. His prior experience includes working on projects at Microsoft, Lucent, Netscape, AOL, and Sun. Most recently he founded the Berkeley DB XML project within Sleepycat software. His three years with Netscape, on the highly successful LDAP Directory server, led to his leading a standardization effort within the IETF, and the filing of numerous patent applications. He continues his work as publications officer of the ACCU, and is a technical reviewer for Addison-Wesley, Prentice-Hall, and APress.
This paper discusses web service authentication and authorization.
1. Introduction
1.1 Authentication
1.1.1 Authentication Mechanisms
1.1.2 Identity Store
1.1.3 Authentication Lifetime
1.1.4 SOAP Authentication
1.1.5 Authentication related Standards
1.1.6 Web Service Authentication in Practice
1.2 Authorization
1.2.1 XACML
1.2.2 Processing Environment
1.2.3 Policy Server
1.2.4 Policy Information Point
1.2.5 SAML
1.3 Conclusion
2. References
This paper discusses web service security, with particular attention to authentication and authorization.
Security is an umbrella term that covers many aspects of web service. This paper is concerned with the external aspects of the service; message security and interface security.
Message security is concerned with integrity and confidentiality. The integrity of a message is assured if it can not be altered in transit, and it’s confidentially is assured if it can not be read by a non-recipient. These security aspects can be achieved with cryptography mechanisms at either the channel or message levels.
Interface security is concerned with authentication and authorization. The service authorizes those who authenticate themselves to perform certain actions against certain resources.
A discussion of authentication is a necessary prerequisite to authorization, as there is no access control without establishing identity.
Authenticating the identity of a client can be achieved in a number of ways, called mechanisms.
Anonymous – The simplest mechanism is no authentication at all.
Basic – The client provides a user name and password. This is insecure as the password is transmitted in the clear over the communications channel.
Basic over SSL – The same as basic authentication, but with channel security to protect the password from eavesdropping.
Digest – The client provides a user name to the service and proves that it knows the password via an exchange of messages. This is more secure than basic authentication as the password is not transmitted in the clear, and without the cost of a secure channel.
Certificate – Public Key Certificates can be used with SSL to authenticate the client.
Token – We defer the actual authentication to a third party that provides the client with a token that can be provided to the service in lieu of authentication.
In general the authentication mechanism describes the exchange of messages that are required to establish the identity of the client. The web service implementation requires an identity store against which to map the identity naming attributes provided in the exchange.
The identity store for the web service implementation can be provided in a number of ways.
Home Grown – A relational database table can be used as a simple identity repository. A typical implementation would be a table containing fields for username and password.
Operating System – Operating systems usually provide an API to their native identity stores. A disadvantage is that the client requires a user account on the service host machine.
Directory Server – An LDAP server can be used as an identity store. For some operating systems this is now the native identity store.
Third Party Service – In the case of the token based authentication mechanism the third party authentication service maintains the identity store.
Another design decision is how long a client remains authenticated with the service.
Message – In the simplest case the client sends authentication information with every request sent to the service.
Connection – The client can authenticate at the start of a connection and the service can assume that all further requests on the same connection are performed within the same authentication context.
Session – The service can provide the client with a token for presentation with every request so that the authentication context can transcend the lifetime of the connection. The lifetime of the session token is determined be the service. It could be valid for a fixed time period, or set to time out after some period of none use.
Subscription – The service can provide the owner of the client with a token upon registration with the web service. The token lives for the lifetime of the subscription to the service.
The SOAP protocol provides neither an authentication mechanism nor an authentication framework. The lack of a framework is unfortunate as many alternative approaches have proliferated. The defensible argument is that authentication should arguably be performed at a lower level in the protocol stack. This pushes responsibility down to the HTTP protocol, or whatever protocol binding SOAP is being used with. In the case of HTTP this provides us with Anonymous, Basic, and Digest.
In the vacuum left by the unwillingness of the SOAP standard’s authors to answer the authentication question other standards have been developed to address the issue.
WS-Security – Provides three main mechanisms: security token propagation, message integrity, and message confidentiality. Ws-Security enables applications to construct secure SOAP message exchanges.
SAML – An OASIS working group has defined the Security Assertion Markup Language, a general protocol for expression of security assertions, of which there are currently three kinds: Authentication, Authorization, and Attribute.
Liberty Alliance – Liberty uses SAML as the basis for its Single Sign On (SSO) architecture.
In practice most web services authors seem to invent their own authentication mechanisms, by adding data fields into the SOAP header or body. Consider the four largest web services that come to mind:
Web Service | Authentication | SOAP Body / Header | Lifetime | Authorization |
token (licenseKey) | Body | Subscription | None | |
Amazon | token (subscriberID, affiliateID) | Body | Subscription | None |
Salesforce | token (sessionID) | Header | Session | Rules |
PayPal | Certificates | N/A | Connection | None |
Table 1
All of them use established authentication mechanisms, and fit within the authentication framework presented here, but none of them utilize the authentications standards available today.
Authorization is the act of determining whether an authenticated identity can perform an action against a resource. Authorization is performed by a service parameterized by an access control policy, which is usually codified as a list of access control rules.
Historically application software stacks have defined their own access control languages and environments. These have tended to be proprietary and specifically tailored to the particular application. For example, even in the thoroughly standardised application domain of LDAP directory servers there is no common access control language. Standardisation brings many benefits including the interoperability of systems, the creation of a market for third party tool support and the portability of IT staff skills.
XACML, sometimes pronounced ‘Zackmul’, is an access control policy language specified by OASIS. The specification defines the syntax and semantics of the language and provides an architectural framework within which it is processed.
An access control policy simply states ‘who can do what to what’. The who is a subject, the what is an action, and the other what is a resource. In real world physical terms the subject could be a person, the action could be the act of opening, and the resource could be a door. In this case the access control policy could be managed with a lock on the door. The person has to be in possession of the key to open the door. In our virtual world the subject could be a user or a process; the action could be a read, a write, a creation, a modification, a deletion; and the resource could be a file, a database record, or an API method.
In general a rule can have the effect of either permitting or denying access. The rule is constrained to the specific subject, resource, and action by the contents of the Subjects, Resources and Actions elements. Attribute values of the identity, resource, and action are combined using functions and operators to produce a matching expression that returns a Boolean value.
The XACML Policy language supports a rich set of data types and functions.
The data types supported are the basic types defined by XML Schema with the addition of data types for email addresses and directory distinguished names: String, Boolean, Integer, Double, Time, Date, DateTime, DayTimeDuration, YearMonthDuration, AnyURI, HexBinary, Base64Binary, RFC822Name, and X500Name.
There are too many functions to list, but they include the simple mathematical operators for all data types, and methods for manipulating sets and bags of values.
An access control policy makes little sense outside of an environment within which subjects are seeking to perform actions against resources. Therefore the XACML specification defines a processing environment and provides terminology for its various components.
The component that processes the policy is called the Policy Decision point, or PDP. The PDP accepts access control requests, processes them against the policy and returns an access control response.
The request and response are also defined as XML, but within an implementation they might never actually exist as documents. Similarly to a policy the request identifies a subject, resource and action. But, the expressions in the request may only contain literal attribute values, and must provide values for the well-known attributes for the subject, resource and action ids.
The Policy Enforcement Point, or PEP, generates the request and consumes the response. In our case the PEP is the web service, which is responsible for authenticating the identity of the subject and for enforcing the result of processing the request against the policy.
The response encapsulates the result of processing the request against the access control policy. The decision can be that of Permit , Deny , NotApplicable , or Indeterminate .
A PDP packaged as a network service, called a policy server, allows multiple different applications, with embedded policy enforcement points, to share the same Policy.
The benefits to application developers are that they no longer need to design and implement their own access control language and processor, they only need to implement an enforcement point. This reduces the cost of application development and ensures that applications have high quality, secure, expressive access control components.
The benefits to an enterprise using a policy server within its web services infrastructure is that a security officer can author an access control policy with confidence that it can be faithfully implemented with fewer errors. The application developers and IT staff who actually implement the policy will have fewer applications to administer and will have access to third party tools for manipulating, testing and deploying policies.
Within an internet or extranet environment the benefits to an enterprise are that the fine grained expressiveness of the language and the lower cost of making changes allows the business managers to be flexible about opening up information and services to their customers, suppliers and partners.
A policy written only against the attribute values provided within a request would not be very flexible. The policy would degenerate into an exhaustive list of subjects, resources, and actions. We would prefer our policies to be written with a higher level of expressiveness. With this in mind the XACML processing environment defines a Policy Information Point, or PIP, from which the PDP can request additional attribute values. Attribute values can be requested for the subject or the resource.
It is implementation dependent how the PDP talks to the PIP, and how the PDP maps the attributes provided in the request onto attribute value requests to the PIP. Within a heterogeneous network environment a Policy Server implementation would have to include PIP connectors for common subject and resource attribute services. Subject attributes are typically stored within servers that are accessed via network protocols such as LDAP, RADIUS, NIS, NT Domain, etc. Resource attribute services might be the file system, or a relational database system.
One solution to the problem of many protocols is to make the network services homogeneous by having them all talk the same protocol. Here we return to the OASIS SAML protocol, and in particular Attribute Assertions.
In the context of a Policy server implementation a SAML Authorization Assertion can be used as the protocol between the PEP and the PDP, and a SAML Attribute Assertion can be used between the PDP and the PIPs.
This has been a rapid tour through web services authentication and authorization.
In addition to the topics covered here XACML also provides structures for managing multiple rules, policies, and policy sets; and different algorithms for processing requests against them efficiently.
The combination of XACML and SAML implemented as a Policy Server deployed within a web-services stack provides a powerful fine-grained access control solution.
As SAML and XACML mature they are attracting interest from both the Web Services and Grid computing communities. Implementations are currently available from Sun Microsystems and Parthenon Computing. Sun are offering a Java implementation as a library provided under an Open Source license. Parthenon are offering a C++ implementation packaged as a testing tool, an OEM library, and as a Policy Server available under a dual open source and commercial license.
Check the Parthenon Computing website for updates to this paper prior to the presentation at XML 2004.
XACML http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
SAML http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
Parthenon Computing http://www.parthenoncomputing.com
Liberty Alliance http://www.projectliberty.org/
WS-Security http://www-106.ibm.com/devleoperworks/webservices/library/ws-secure/
Xmethods http://www.xmethods.net
XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.