Chapter 6: SAML


Blending the S2ML and AuthML specifications, the Secure Assertion Markup Language (SAML) is a complex specification developed through OASIS, and currently has “OASIS Open Standard” status. This chapter will explain SAML 1.0 in the context of use cases. SAML, almost by definition, is designed to work in the background and be invisible to the user; therefore, it can be difficult to understand such a “hands-off” technology. You are probably already familiar with the concept of single sign-on, and Kerberos in particular. In addition, you have read about the need to separate security policy decision making from security policy enforcement—these are important bedrocks of the SAML specification.

How SAML Enables “Portable Trust”

The OASIS SAML specification allows trust assertions to be specified using XML. These assertions can concern authorizations, authentications, and attributes of specific entities, whether these be individuals or computer systems. These entities must be identifiable within a specific security context, such as a human who is a member of a workgroup or a computer that is part of a network domain. An assertion can be defined as a claim, statement, or declaration. This means that assertions can only be accepted as true subject to the integrity and authenticity of the entity making the assertion. That’s why the authorities for attributes and for authentication play a key role in the SAML model. Essentially, if you can trust the authority making the assertion, the assertion can be accepted as true with the same level of certainty as any other certification authority can be trusted.

In addition to assertions, the SAML specification also defines a client/server protocol for exchanging XML message requests and responses. As with all Web Services, the underlying transport protocol is not mandated, with SOAP running over HTTP being the most likely configuration. SAML data can be identified in XML documents by two prefixes: saml: specifies an assertion, while samlp: indicates usage of the SAML client/server protocol.

SAML enables “portable trust” by supporting the assertion of authentication of single principals between different (and potentially multiple) domains. Why is this an important goal for Web Services? In cooperative B2B e-commerce systems involving a number of different companies where there is an aggregation of services offered through a single intermediary, all participants (customers, partners, staff, and systems) need to be authenticated in the same way across the entire virtual system. This model relies upon authoritative systems for each organization being capable of authentication for all subjects within their home domain, in order to allow seamless and secure execution of remote services, as shown in Figure 6-1. Here, two businesses (A and B) have their own security and authentication domains (domain A and domain B, respectively). Normally, a service offered within domain A or domain B is only available to principals (users and systems) that have been authenticated by a server in their own domain. Thus, users and systems in domain A can access a service in domain A because the authentication server - domain A has authenticated them. However, what if principals from domain A wish to invoke services in domain B?

click to expand
Figure 6-1: Portable trust authentication

This model prevents two very difficult scenarios from occurring. First, one organization would have to take on the responsibility for authenticating all foreign principals. Not only would this introduce a heavy administrative burden on the authenticating organization, it would be unacceptable to the other participants in the enterprise. For example, a bank is not going to hand over its authentication data to an external party just so that party can invoke a service from the bank, and vice versa. Returning to our Figure 6-1 example, authentication for domain A would now have to be undertaken by the authentication server - domain B. This solution, as shown in Figure 6-2, would not be palatable by the administrators of domain A!

click to expand
Figure 6-2: Interdomain authentication issues

Setting up a central authentication registry for every partnership that an organization has developed would be necessary if principals from both organizations were able to invoke each other’s services. This approach requires setting up and maintaining a new authentication registry for every partnership, which would be very costly. Allowing all parties in a transaction to accept each other’s authentication tokens as valid prevents reauthentication to the viral-like distribution of credentials. Returning to the example shown in Figure 6-1, a new server called authentication server – domain C would have to be created in order to allow the sharing of credentials between domain A and domain B, into a new “super” domain C, as shown in Figure 6-3. The questions of who maintains and pays for this new service, who manages it, and how to handle crossover of confidential information between the servers are not easily resolved.

click to expand
Figure 6-3: Centralized interdomain authentication issues

Clearly, allowing individual domains to retain their own internal authentication systems provides the best solution to the proliferation of authentication systems and related issues such as the integrity of credentials if they are distributed. This provides the “loose coupling” of authentication systems, by means of assertions, that are provided in other Web Services, such as the decoupling of message format from transport type. Removing the brittleness from the authentication process makes it infinitely more flexible. However, in order to allow principals from one domain to invoke services in another domain, assertions must be made about an authenticated principal after the single sign-on has occurred and a trust relationship has been established.

Introducing the Three Types of Assertions

From a client perspective, being able to have a single sign-on also reduces the difficulties involved in accessing multiple services from multiple providers—after a principal has been authenticated once, an assertion about that authentication can be made each time an authentication point is reached in a business process. For example, in a B2C e-commerce application, a client can use the same authentication assertion to access a bank account as well as a merchant’s shopping basket. However, it’s important to note that assertions are not limited to authentication—they also include attributes and authorizations. For example, if the client has $1,000 available credit, the bank may authorize a withdrawal of that amount with respect to the purchase from the merchant. Rather than having to pass credit card details to the merchant, the merchant accepts the assurance from the bank that the client can pay for the goods ordered.

A set of assertions is known as a profile. A principal’s profile can comprise assertions made by different organizations, which is acceptable as long as the entities trust each other. For example, computer records in different government departments could be combined together to form a “citizen” profile, which might contain authorizations like the following:

  • Can reside in the country without restrictions

  • Can drive a motor vehicle

  • Can pay taxes

  • Can claim social security

  • Can travel internationally with a valid passport

Each of these authorizations may be granted by a different department, even within different jurisdictions, but a profile can nonetheless be constructed and data exchanged by using SOAP. The profile can potentially be shared by all of the parties involved in administering authorizations. Of course, the citizen might want to control just what information is shared. Just because the technology makes it possible, doesn’t mean it should happen unfettered.

Profiles are used in real-world applications to authorize specific types of activities, based on policies. For example, in order to authorize a claim for social security, a citizen may need to have the authorizations “Can reside in the country without restrictions” and “Can pay taxes,” while “Can drive a motor vehicle” would not be relevant. The exception would be where the primary key for identifying principals (such as a driver’s license number) was used in other domains, as occurs frequently in government (for example, social security numbers). Each of the business logic decisions would be encapsulated in the relevant policy.

In the following sections, we will examine each type of assertion in detail.

Explanation of the Concept of an “Assertion”

SAML provides three types of assertions: authentication assertion, authorization decision assertion, and attribute assertion. Each type of assertion can have its own policies, profiles, and attributes. It can be very confusing to discuss the attributes of the attribute assertion, but the correct type can usually be identified from context. The following elements are common to all assertions:

  • <Advice> Contains additional evidence relating to the assertion.

  • <Assertion> Contains the data elements for all assertion types.

  • <AssertionIDReference> Refers to a SAML assertion.

  • <Audience> Contains the URI for the intended audience.

  • <AudienceRestrictionCondition> Restricts the potential audience of an assertion.

  • <Conditions> Specifies logical conditions that the assertion is subject to.

An <Assertion> is specified using an AssertionType, which is comprised of the following elements:

  • <AttributeStatement> Statement relating to an attribute.

  • <AuthenticationStatement> Statement relating to authentication.

  • <AuthorizationDecisionStatement> Decision relating to authorization.

  • <ds:signature> XML digital signature for authentication.

  • <Statement> General extension schema statement for external applications.

  • <SubjectStatement> Extension schema statement relating a principal.

  • AssertionID Unique ID of IDType.

  • IssueInstant Time when the assertion was made.

  • Issuer Name of the assertion issuer.

  • MajorVersion The assertion’s major version.

  • MinorVersion The assertion’s minor version.

In addition to assertions, the following common statements are supported:

  • <Statement> General extension schema statement for external applications.

  • <SubjectStatement> Extension schema statement relating a principal.

  • <Subject> Defines a principal related to a statement.

  • <NameIdentifier> Defines a principal by using a NameQualifier, a name, and a specific format.

  • <SubjectConfirmation> Specifies an authentication protocol to authenticate a principal using a specific <ConfirmationMethod> and any additional data in <SubjectConfirmationData>.

  • <AuthenticationStatement> Specifies that a principal was authenticated by an external authority at a specific date and time.

  • <SubjectLocality> Contains the IP address and DNS name of the authenticated system.

  • <AuthorityBinding> Specifies details about a SAML authority.

  • <AuthorizationDecisionStatement> URI that states a decision concerning an authorization based on a set of evidence.

Authentication Assertion

The authentication authority receives a set of credentials from the credentials collector, and processes them according to a specific policy. An authentication assertion can then be made with respect to the two other assertions (authorization decision assertion and attribute assertion), if the authority determines that the credentials are valid. The assertion defines several authentication elements such as the identity of the issuer and the principal, the time the authentication was granted, and how long the authentication is valid for. The assertion clearly indicates that a principal was authenticated by a specific system at a specific point in time—unlike, say, traditional UNIX authentication, which is all or nothing.

The <AuthenticationStatement> is generated after authentication and contains the method by which the principal was authenticated, the time it occurred, and where it occurred. The <SubjectLocality> element specifies the DNS name and IP address of an authenticating system, while the <AuthorityBinding> element indicates that additional data concerning a principal may be available.

The following authentication methods are supported:

  • Passwords

  • Kerberos

  • Secure Remote Password (SRP)

  • Hardware token

  • Certificate-based client authentication (SSL/TLS)

  • X.509 public key

  • Pretty Good Privacy (PGP) public key

  • SPKI public key

  • XKMS public key

  • XML digital signature

Attribute Assertion

An attribute assertion begins with an attribute authority accepting an authentication assertion and using a policy to determine the privileges of a principal. The attribute assertion can be passed to a policy decision point (PDP) for authorization.

The <AttributeStatement> contains <Subject>, <Attribute>, <NameIdentifier>, <SubjectConfirmation>, <ConfirmationMethod>, and <SubjectConfirmationData> elements. The <AttributeDesignator> element defines the attributes involved in a request with respect to a specific namespace, and includes the <AttributeName> and associated <AttributeNamespace> elements. The <Attribute> element itself contains the attribute value <AttributeValue>, related to the underlying assertion.

Authorization Decision Assertion

An authorization decision assertion involves making a decision about whether or not a principal can access a specific resource, given an authentication assertion and an attribute assertion. It involves two entities: the policy decision point (PDP) and the policy enforcement point (PEP). According to a policy, the PDP and PEP make and enforce authorization decisions, respectively. Obviously, requests for authorization to access resources can be accepted (Permit), can be denied (Deny), or cannot be determined (Indeterminate); hence, the importance of an authority’s decision-making process.

The <AuthorizationDecisionStatement> specifies what decision was made with respect to an authorization decision assertion request. The <AuthorizationDecision Statement> contains a resource URI, which identifies the resource that the principal is attempting to access; a decision, which states whether access is granted or denied; an action, specifying what the principal is authorized to do; and optionally the evidence upon which the decision was taken.

SAML Architecture

Fundamentally, SAML is concerned with access control for authenticated principals based on a set of policies. The applications and environment that can potentially use SAML are quite varied, from simple browser-based applications running over HTTP to full-blown J2EE applications supporting n-tier architectures. There are two actions that must be performed with respect to access control in any enterprise system: making decisions about access control based on a set of policies, and enforcing those decisions at the system level. The SAML architecture provides two roles for performing these actions: the policy decision point (PDP) and the policy enforcement point (PEP), respectively. If a PDP is external to the system, it will need to have access to a policy retrieval point (PRP) in order to retrieve policies relevant to decisions being made. This connection should use a secure transport; otherwise, details of policies may become public.

A PDP makes decisions concerning access control based on one or more parameters and/or their logical combination. This means that simple types of access can be granted, such as whether or not a user is using a secure transport layer like HTTPS. Or, more complex types of access can be granted, such as whether a specific group member is attempting access at a specific time on a specific day. For example, a commodities trader should only be able to trade stocks within certain time periods during the day, so access will be denied outside of those times. The parameters that can be used to make decisions about access control include the following:

  • Whether a user has exceeded a limit on the number of accesses to a specific service

  • Whether a user is a member of a specific group

  • Whether a user is a member of an organization

  • Whether the client can establish a secure connection

  • Whether the client can supply an authentication credential

  • Whether the client’s hostname or IP address is valid

  • Whether the current day lies within the boundaries defined as legal

  • Whether the current time lies within the boundaries defined as legal

In order to prevent denial of service attacks, it would also be useful to log all access attempts and to block incoming connections from a specific client if they persist in requesting a resource to which they have no access. This could potentially be achieved in combination with an XML firewall.

PEPs and PDPs

The IETF/DMTF policy framework (http://www.ietf.org/html.charters/policy- charter.html) specifies that a policy repository should store the different policies that can be applied to services on a specific server, and that a policy management tool can be used to set specific policies. Where a single management tool can be used to centralize administration of common policies across many systems, the administrative burden required to manage access control policies can be greatly reduced. Policy management tools, at a minimum, need to provide a user-friendly interface to discover resources, encapsulate transformational logic for ensuring the consistency of sets of policies applied to the same principals, and provide a reliable method for distributing policies around the network. Policies can be evaluated in real time or at the time of creation for boundary error conditions, logical relation satisfaction, policies that will never be satisfied under any situation, and whether a set of policies delivers a desirable outcome. The framework also defines the activities of PEPs and PDPs with respect to policy processing. When an enforcement decision is required, a PEP makes a connection to the appropriate PDP for the decision. The policy function is evaluated with data supplied from the PEP to the PDP. Clients make their connections to SAML authorities by using the SAML client/server protocol, where a <Request> is always answered with a specific <Response>.

Imagine a set of four policies with the following parameters in a share-trading environment of a financial institution:

  • Members of group Clients can access the service BuyStocksConsumer.

  • Members of group Brokers cannot access the service BuyStocksConsumer.

  • Members of group Clients cannot access the service BuyStocksStaff.

  • Members of group Brokers can access the service BuyStocksStaff.

The purpose of these policies is to allow clients to buy stocks using the consumer interface, while brokers cannot use the same interface. Instead, they must use a special staff interface that is not available to consumers. Now, when the PEP passes a decision request for access control to the PDP, the PDP must logically evaluate the inputs it receives with respect to these rules. If these rules are consistent, the processing is trivial, and if a match is made against any policy, it will be returned positively. For example, if Joe.Bloggs@iBuyStocks.com is a member of Clients, a match will be made against the first policy and access will be granted to BuyStocksConsumer. However, what happens if Joe.Bloggs is both a member of Clients and Brokers? Clearly, the first and second policies are inconsistent in this case, and the PDP policy evaluation engine must be able to detect the mismatch, and not just return a positive evaluation of Joe.Bloggs after processing only the first policy. This suggests that O(p2) time is required to cross-check each set of policies for consistency, where p is the number of applicable policies.

Example Architecture

Let’s examine a simple application at this point to show how the decision process actually works in an authentication scenario. In the following example, Joe.Bloggs is the principal, and the SecurityDomain is iBuyStocks.com. The AttributeName is the username, the AttributeNamespace is the same as the SecurityDomain, and the request is an AttributeQuery, which should return the appropriate attributes for the user involved, as shown in the following example request code:

<samlp: Request>       <samlp: AttributeQuery>             <saml: Subject>                   <saml: NameIdentifier SecurityDomain="iBuyStocks.com" Name="joe.bloggs"/>             </ saml: Subject>             <saml: AttributeDesignator AttributeName="username" AttributeNamespace="iBuyStocks.com">             </ saml: AttributeDesignator>       </ samlp: AttributeQuery> </ samlp: Request> 

The response is shown next, where the authentication is validated against a previous Kerberos authentication of the principal. Some key characteristics of the authentication are displayed, including the time period for which it is valid, the time at which it was granted, and the method used.

<samlp: Response MajorVersion="2" MinorVersion="1" Request InResponseTo="192.192.208.64.77645543" StatusCode="Success">       <saml: Assertion MajorVersion="1" MinorVersion="0" Assertion Issuer="iBuyStocks.com" IssueInstant="2002-11-16T10: 00: 23Z">             <saml: Conditions NotBefore="2002-11-16T10:01:00Z" NotOnOrAfter="2002-11-23T10:01:00Z" />             <saml: AuthenticationStatement AuthenticationMethod="Kerberos" AuthenticationInstant="2002-11-16T10:00:00Z">                   <saml: Subject>                         <saml: NameIdentifier SecurityDomain="iBuyStocks.com" Name="joe.bloggs" />                   </ saml: Subject>               </ saml: AuthenticationStatement>       </ saml: Assertion> </ samlp: Response>

Access Control

One of the useful features of SAML is the ability to map access control elements to those used by the most common systems. This means that developers do not need to implement their own systems for access control. The control types covered in the following subsection are supported.

Read, Write, Execute, Delete, Control These controls are the standard ones found on most operating systems:

  • Read Principal can read data.

  • Write Principal can write data.

  • Execute Principal can execute the application.

  • Delete Principal can delete data.

  • Control Principal is allowed to stipulate access control policies.

The URI for this action is “urn:oasis:names:tc:SAML:1.0: action:rwedc”. An alternative is read, write, execute, delete, control, negation, which allows all or any of the access controls to be specifically denied. The URI for this alternative action is “urn:oasis:names:tc:SAML:1.0: action:rwedc-negation.”

Get, Head, Put, Post These actions correspond to the HTTP operations of the same name, with Get and Head reading data from a server, and Put and Post writing data to a server. The URI for the action is urn:oasis:names:tc:SAML:1.0: action:ghpp.

UNIX Permissions UNIX permissions can be set using either symbolic or octal codes. For example, the attribute “+rwx” would grant read, write, and execute permissions on a file using symbolic codes, while 0777 would be the octal equivalent. The URI for this action is urn:oasis:names:tc:SAML:1.0:action:unix.




Web Services Security
Web Services Security
ISBN: 0072224711
EAN: 2147483647
Year: 2003
Pages: 105
Authors: Mark ONeill

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net