SOA Security

SOA Security and WS-Federation

2007-02-19T19:00:00.000-08:00

SOA is being used to support organizations in collaboration in the creation of virtual organizations for mutual benefit. A crucial building block in the creation of virtual organizations is the federation of identity information, allowing transparent access across security domains for users based on trustrelationships that are established between the participating organizations. While WS-Federation does not address the specifics of how trust relationships are established, itprovides a metadata exchange framework to allow organizations to provide services that leverage these trust relationships. WS-Federation is a component of the WS-Security family of standards and has been created to support the federation of security domains, which allows users whose identity information exists in one security domain to access resources in another security domain. This is enabled by the abilityto broker identity data including indentity, authentication, authorization and attribute information between security domains, through the use of mechanisms selected based on the relationship of trust that exists between the security domains. WS-Federation provides astandard way for security domains to exchange metadata in order to indicate the trust relationships between these security domains. This is an overview of the contents of the WS-Federation Version1.1 Specification published in December 2006.

An important aspect of the WS-Federation approach is that an organization needs to be able to use their existing identity management infrastructures in order to support identity federation, with minimal new investment required in order to participate. For this reason, the range of supported security tokens, attributes and discovery approaches are designed to support the range of technologies that are already in place as a foundation. The approach also does not specify specific trust toplogies, tools and relationships, deliberately in order to provide flexibility to allow the ability to participate in identity federation independently of what the existing infrastructure consists of. Furthermore, the approach is designed to be extensible to make it easy to integrate new approaches to identity and trust management that may be developed going forward.

WS-Federation exists within a family of other WS-*standards. It rests on a foundation of WS-Security and WS-Trust that contain the primitives necessary to define security tokens, trust topologies and security infrastructures. The primitives defined in WS-Policy and WS-SecurityPolicy, along with extensions that are defined as part of theWS-Federation specification, are indended to support the definition of policies that identify what the supported and required components of a federation are by participating members, and what the choices are for communicating the policy information between federation participants.

There are two types of requesters that are supported by WS-Federation, Web services and Web browser based requesters. Identity mapping could be done at the target service, the requestor, the identity provider, or an intermediate security token service. In order to provide privacy inthe situation where identity mapping is performed by the resource that the user is accessing, WS-Federation includes the specification of a service called a pseudonym service that provides the federated identity for the mapping. In this situation therequestor obtains, through the leverage of these trust relationships, a security token that the target service can accept. In this case, the target service has no way of knowing that the requestor is in another security domain.

2. Alternate Federation and Trust Model

In the case where there do not exist trust relationships between the requestor and its identity provider/security token service, or between the target service and its own identity provider/token service, the target service will need to use its own security token service to validate the token provided by the requestor. In this case, the target service is aware that the requestor is in another security domain.

3. Indirect Trust Model

In the indirect trust model, there is no direct trust relationship between the requestor's security token service and the target service's security token service, but trust relationships that both securitytoken services have with a third party security token service are leveraged in order to provide a security token to the requestor that will work with thetarget service.

4. Multiple Trust Domain Model

In the multiple trust domain model, the requestor accesses target services that exist in more than one other security domain, by leveraging trust relationships between the requestor's security token service and the security token services for the set of target services.

5. Trust Between Requestor-Resource and Resource-Delegate Resource

In this trust topology, a requestor accesses a target service leveraging a trust relationship between its security token service andthe target service's security token service, and the target service delegates its work to a delegate service leveraging a trust relationship between the target service's security token service and the delegate service's security token service.

6. No Trust Relationship Between Resource Providers

This trust topology exists when a requestor accesses a target service leveraging a trust relationship between its security token service and the target service's security token service, and the target service's security token service has no trust relationship with a delegateservice's security token service, but there is a trust relationship between the requestor's security token service and the delegate service's security token service.

Identity Providers and Security Token Services

A Security Token Service (STS) is a service that will issue and exchange security tokens. A Webservice that conforms to the WS-Trust specification may act as its own STS. Another type of STS is an identity provider that authenticates users and issues security tokens that contain identity claims. Sometimes an identityprovider and STS will reside in the same service. In other cases, an identity provider can access an STS to provide security tokens to requestors after they have been authenticated by the identity provider.

Attributes and Pseudonyms

Attributes are used to exchange information about requestors that are not already included in security tokens or requests. Pseudonym services provide account management for pseudonyms and the ability to issue, update and revoke pseudonyms

Federation Metadata

Federation metadata can be represented as a document that contains metadata for an endpoint existing in one or more federations, for one or more services, with one or more MEPRs per service, can refer to external metadata documents, and can be contained inside a service's WSDL description.

Federation Metadata Document

The federation metadata document is structured as follows:

<?xml version="1.0" encoding="..."?>

<fed:FederationMetadata xmlns fed="..." ...>

<fed:Federation[FederationID="..."= ...>

[FederationMetadata]

</fed:Federation>

[Signature]

</fed:FederationMetadata>

The FederationID attribute is an optional URI designating a pecific federation, but can be left out which is interpreted as the default federation, or at most one Federation element in the FederationMetadata document. The [Federation Metadata] property consists of a set of optional metadata statements. The [Signature] property consists of an XML Digital Signature on the metadata document content, which provides integrity and data origin authentication for the metadata document.

Any federation participant's metadata document can containthe following metadata elements

1. mex:MetadataReference

2. fed:AttributeServiceEndpoint

A Security Token Service's metadata document can contain the following metadata elements:

1. fed:TokenSigningKeyInfo

2. fed:PseudonumServiceEndpoint

3. fed:SingleSignOutSubscriptionEndpoint

4. fed:TokenTypesOffered

5. fed:UriNamedClaimTypesOffered

6. fed:AutomaticPseudonyms

7. fed:IssuerNamesOffered

A Service Provider or Relying Party's (which can be aSecurity Token Service) metadata document can contain the following elements:

1. fed:TokenIssuerName

2. fed:TokenIssuerEndpoint

3. fed:TokenKeyTransferKeyInfo

4. fed:SingleSignoutNotificationEndpoint

In order to reference another metadata document, a mex:MetadataReference element is used which refers, using theWS-MetadataExchange specification, to another metadata document which has the same federation identification. Metadata documents can also share elements by using the fed:FederationInclude element and be named using URIs.

The TokenSigningKeyInfoElement of the Federation MetadataDocument

Security Token Services and other token issuers need to beable to indicate to metadata users what key it will use to sign security tokens that it issues. The fed:TokenSigningKeyInfo Element is used to specify this key and has the following structure:

<fed:TokenSigningKeyInfo ...>

<wsse:SecurityTokenReference>

...

</wsse:SecurityTokenReference>

</fed:TokenSigningKeyInfo>

The wsse:SecurityTokenReference can contain any child element of the ds:KeyInfo element defined in the XML-Signature specification. This element can be specific to a service or an endpoint.

The TokenKeyTransferKeyInfo Element of the FederationMetadata Document

Security Token Services and Relying Parties need to be able to indicate which key requestors need to use to encrypt key information that is to be sent to them. The fed:TokenKeyTransferKeyInfo element is used for this purpose and has the following structure:

<fed:TokenKeyTransferKeyInfo ...>

<wsse:SecurityTokenReference>

...

</wsse:SecurityTokenReference>

</fed:TokenKeyTransferKeyInfo>

The wsse:SecurityTokenReference element can contain any child element of the ds:KeyInfo element defined in the XML-Signature specification. This element can be specific to a service or an endpoint.

The IssuerNamesOffered Element of the Federation MetadataDocument

Token issuers can be part of a set of equivalent issuers. Relying parties need to verify that the token issuer is a member of the set in order to be able to use the token issuer. The fed:IssuerNamesOffered element is used for this purpose and has the following structure:

<fed:IssuerNamesOffered ...>

<fed:IssuerNameUri="xs:aURI" .../> ...

</fed:IssuerNamesOffered>

This element can be specific to a service or an endpoint.

The TokenIssuerName Element of the Federation MetadataDocument

Relying parties need to be able to indicate that they are included in a set of equivalent issuers. The fed:TokenIssuerName element is used for this purpose and has the following structure:

<fed:TokenIssuerName...>xs:aURI</fed:TokenIssuerName>

This element can be specific to a service or an endpoint.

The TokenIssuerEndpoint element of the Federation MetadataDocument

A relying party needs to be able to indicate to other federation members what Security Token Service that it trusts so that the other federation members can know where to go to get security tokens that can be used to access the relying party. TheTokenIssuerEndpoint element is used for this purpose and has the following structure:

<fed:TokenIssuerEndpoint>

wsa:EndpointReferenceType

</fed:TokenIssuerEndpoint>

The wsa:EndpointReferenceType indicates that an endpoint reference conforming to the WS-Addressing specification is used to specify the endpoint. This element can be specific to a service or an endpoint.

The PseudonymServiceEndpoint Element of the FederationMetadata Document

Token issuers and Security Token Services need to be able to indicate which pseudonym service that services should use when they want to map user identities. ThePseudonymServiceEndpoint element is used for this purpose and has the following structure:

<fed:PseudonymServiceEndpoint>

wsa:EndpointReferenceType

</fed:PseudonymServiceEndpoint>

The AttributeServiceEndpoint Element of the FederationMetadata Document

Requestors need to be able to provide a way to indicate to services where to send queries for attribute information that may be required in order to process requests. The AttributeServiceEndpoint element is used for this purpose and has the following structure:

<fed:AttributeServiceEndpoint>

wsa:EndpointReferenceType

</fed:AttributeServiceEndpoint>

The wsa:EndpointReferenceType indicates that an endpoint reference conforming to the WS-Addressing specification is used to specify the endpoint. This element is a service level element.

The SingleSignOutSubscriptionEndpoint Element of the Federation Metadata Document

Token issuers and Security Token Services need to be able to specify a subscription endpoint for them to send sign out messages to.

<fed:SingleSignOutSubscriptionEndpoint>

wsa:EndpointReferenceType

</fed:SingleSignOutSubscriptionEndpoint>

The SingleSignOutNofificationEndpoint Element of the Federation Metadata Document

Service providers and Security Token Services need to be able to register to receive notification when a requestor has signed out of the federation. The SingleSignOutNotification element is used for this purpose and has the following structure:

<fed:SingleSignOutNotificationEndpoint>

wsa:EndpointReferenceType

</fed:SingleSignOutNotificationEndpoint>

The TokenTypesOffered Element of the Federation Metadata Document

Token issuers and Security Token Services need to be able to indicate which token types they support. The TokenTypesOffered element is used for this purpose and has the following structure:

<fed:TokenTypesOffered ...>

<fed:TokenType Uri="xs:aURI" ...>

...

</fed:TokenType>

...

</fed:TokenTypesOffered>

One or more fed:TokenType elements are used to specify the set of token types that are provided. A URI attribute can be used to specify a token type. The TokenTypesOffered element is extensible. Additional elements and attributes can be included in the TokenTypesOffered and TokenType elements if they preserve the existing semantics of the WS-Federation specification.

The UriNamedClaimTypesOffered Element of the FederationMetadata Document

Token Issuers and Security Token Services need to be able to specify the set of claims that they offer to service providers given the identity of a requestor. The UriNemedClaimTypesOffered element is used for this purpose and has the following structure:

<fed:UriNamedClaimTypesOffered ...>

<fed:ClaimTypeUri="aURI" ...>

<fed:DisplayName...>xs:string</fed:DisplayName>

<fed:Description...>xs:string</fed:Description>

...

</fed:ClaimType>

...

</fed:UriNamedClaimTypesOffered>

The UriNamedClaimTypesOffered element is extensible. Additional elements and attributes can be included in the UriNamedClaimTypesOffered, ClaimType, DisplayName and Description elements if they preserve the existing semantics of the WS-Federation specification.

The AutomaticPseudonyms Element of the FederationMetadata Document

Token issuers and Security Token Services need to be able to indicate whether they either perform the automatic mapping of pseudonyms or otherwise perform identity mapping. The AutomaticPseudonyms element is used for this purpose and has the following structure:

<fed:AutomaticPseudonyms>

xs:boolean

</fed:AutomaticPseudonyms>

The Signature Property of the Federation Metadata Document

The Signature property of the metadata document is used to provide data origin authentication and data integrity for the federation metadata. XML Signature is recomended, and if used it is required that XML Exclusive Canonicalization is used.

Federation Metadata Discovery

If a relying party needs to obtain federation metadata given nothing more than the DNS host name of a service then the following processing order is recommended by the WS-Federation specification:

1. HTTPS GET, WS-Transfer/WS-ResourceTransfer GET (WS-Security is recommended), and HTTP GET are preferred in the listed order.

2. The federation ID should be used before accessing metadata using the default federation.

The federation metadata document can be contained within a service's WSDL description.

The recommended federation metadata path is as follows:

https://server-name/FederationMetadata/specification-version/federation-id/FederationMetadata.xml

http://server-name/FederationMetadata/specification-version/federation-id/FederationMetadata.xml

https://server-name/FederationMetadata/specification-version/FederationMetadata.xml

http://server-name/FederationMetadata/specification-version/FederationMetadata.xml

The FederatedMetadataHandler Header

Services may be configured with a pre-processing service that handles federation metadata requests. The FederatedMetadataHandler header is used to identify metadata requests for this purpose. This is accomplished by including the following element in the header of a SOAP
message:

<fed:FederationMetadataHandler .../>

The Metadata Exchange Dialect

The metadata exchange dialect is used when including the federation metadata documents as an element in a Web service's mex:Metadata element conforming to the WS-MetadataExchange specification. This is done by specifying the metadata dialect URI using an attribute on a mex:MetadataSection element which contains the Federation Metadata Document:

<mex:MetadataSection
Dialect="http://schemas.xmlsoap.org/ws/2006/12/federation">

<fed:FederationMetadata ...>

...

</fed:FederationMetadata>

</mex:MetadataSection>

This can be used to provide backward compatiblity as subsequent versions of the WS-Federation specification may be published.

Publishing Federation Metadata Location

The WS-Federation specification recommends that domains publish federation metadata using SRV resource records in DNS databases.

The _Service.Protocol.TargetDnsDomain is used to specify the available protocols by which the metadata is available, which may be one or more of HTTP, HTTPS or WS-Transfer/WS-ResourceTransfer, by specifying the owner name of the SRV record as:

1. _fedMetadata._http.TargetDnsDomain in order to indicate that metadata is available via HTTP

2. _fedMetadata._https.TargetDnsDomain in order to indicate that metadata is available via HTTPS

3. _fedMetadata._wsxrf._http.TargetDnsDomain in order to indicate that metadata is available via WS-Transfer/WS-ResourceTransfer

In addition, priority (load balance priority), weight (load balance weight), port (port that the service is available on) and target (domain name) information is included in the SRV record.

The WS-Federation specification recommends that metadata providers include a signature element and that metadata consumers validate the signature elements of federation metadata documents.

Federated Sign-Out

Federated sign-out is used to give relying parties the ability to reclaim resources that had been consumed in order to support a user session within the federation. Sign-out is accomplished by sending an optional message.

The Sign-Out Message

When a requestor chooses to terminate a federation Single Sign-On session they will send a Sign-Out message to the Identity Provider or Security Token Service that they used to authenticate within the federation with. The mssage structure is as follows:

<fed:SignOut wsu:Id="..." ...>

<fed:Realm>xs:aURI</fed:Realm>

<fed:SignOutBasis ...>...</fed:SignOutBasis>

...

</fed:SignOut>

...

</fed:SignOut>

The optional fed:Realm element indicates a realm that the sign-out is operational for. The mandatory fed:SignOutBasis can is used to specify the principal that is signing out. The optional ID element is a label for the SignOut message. The SignOut message is extensible. Additional elements and attributes are allowed to be included in the SignOut and SignOutBasis elements if they do not modify the semantics of the WS-Federation specification. The WS-Federation specification recommends that SignOut messages be signed in order to prevent SignOut of a principal by an unauthorized entity.

Federating the Sign-Out Message

In order to share sign-out information with all relying parties that a user has accessed in the federation, a method of sending federated sign-out messages is needed. This can be accomplished by having Security Token Services send sign-out messages to secondary Security Token Services, or by using WS-Eventing to create subscriptions to federated sign-out messages. These messages can be filtered in two ways.

<wsrt:Expression>

<fed:FilterPseudonyms>

<fed:PseudonymBasis>

<wsse:BinarySecurityToken>...</wsse:BinarySecurityToken>

</fed:PseudonymBasis>

<fed:RelativeTo>

<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>

</fed:RelativeTo>

</fed:FilterPseudonyms>

</wsrt:Expression>

</wsrt:Get>

</S:Body>

</S:Envelope>

This is an example reply:

<S:Envelope xmlns:S=:"..."xmlns:wsa="..." xmlns:wsxf="..." xmlns:fed="..."

xmlns:wsu="..." xmlns:wsse="..."xmlns:wsrt="...">

<S:Body>

<wsrt:GetResponse>

<wsrt:Result>

<fed:Pseudonym>

<fed:RelativeTo>

<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>

</fed:RelativeTo>

<wsu:Expires>2007-02-18T20:04:00Z</wsu:Expires>

<fed:SecurityToken>...</fed:SecurityToken>

<fed:ProofToken>...</fed:ProofToken>

</fed:Pseudonym>

</wsrt:Result>

</wsrt:GetResponse>

</S:Body>

</S:Envelope>

Setting Pseudonyms

Pseudonyms are set in a Pseudonym Service using the WS-ResourceTransfer extensions to WS-Transfer in a wsrt:Put element, contained in a wsrt:Fragment element with the value of the Mode attribute set to "Insert".

Here's an example:

<S:Envelope xmlns:S=:"..."xmlns:wsa="..." xmlns:wsxf="..." xmlns:fed="..."

xmlns:wsu="..." xmlns:wsse="..."xmlns:wsrt="...">

<S:Body>

<wsrt:PutDialect="http://schemas.xmlsoap.org/ws/2006/12/federation/pseudonymdialect">

<wsrt:Expression Mode="Insert">

<fed:FilterPseudonyms>

<fed:PseudonymBasis>

<wsse:BinarySecurityToken>...</wsse:BinarySecurityToken>

</fed:PseudonymBasis>

<fed:RelativeTo>

<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>

</fed:RelativeTo>

</fed:FilterPseudonyms>

</wsrt:Expression>

<wsrt:Value>

<fed:Pseudonym>

<fed:RelativeTo>

<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>

</fed:RelativeTo>

<fed:SecurityToken>...</fed:SecurityToken>

<fed:ProofToken>...</fed:ProofToken>

</fed:Pseudonym>

</wsrt:Value>

</wsrt:Put>

</S:Body>

</S:Envelope>

Deleting Pseudonyms

Pseudonyms are deleted in a Pseudonym Service using the WS-ResourceTransfer extensions to WS-Transfer in a wsrt:Put element, contained in a wsrt:Fragment element with the value of the Mode attribute set to"Remove".

Here's an example:

<S:Envelope xmlns:S=:"..."xmlns:wsa="..." xmlns:wsxf="..." xmlns:fed="..."

xmlns:wsu="..." xmlns:wsse="..."xmlns:wsrt="...">

<S:Body>

<wsrt:PutDialect="http://schemas.xmlsoap.org/ws/2006/12/federation/pseudonymdialect">

<wsrt:Expression Mode="Remove">

<fed:FilterPseudonyms>

<fed:PseudonymBasis>

<wsse:BinarySecurityToken>...</wsse:BinarySecurityToken>

</fed:PseudonymBasis>

<fed:RelativeTo>

<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>

</fed:RelativeTo>

</fed:FilterPseudonyms>

</wsrt:Expression>

</wsrt:Put>

</S:Body>

</S:Envelope>

Creating Pseudonyms

Pseudonyms are created in a Pseudonym Service using the WS-ResourceTransfer extensions to WS-Transfer in a wsrt:Put element, contained in a wsrt:Create element.

Here's an example:

<S:Envelope xmlns:S=:"..."xmlns:wsa="..." xmlns:wsxf="..." xmlns:fed="..."

xmlns:wsu="..." xmlns:wsse="..."xmlns:wsrt="...">

<S:Body>

<wsrt:CreateDialect="http://schemas.xmlsoap.org/ws/2006/12/federation/pseudonymdialect">

<wsrt:Expression Mode="Insert">

<fed:FilterPseudonyms>

<fed:PseudonymBasis>

<wsse:BinarySecurityToken>...</wsse:BinarySecurityToken>

</fed:PseudonymBasis>

<fed:RelativeTo>

<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>

</fed:RelativeTo>

</fed:FilterPseudonyms>

</wsrt:Expression>

<wsrt:Value>

<fed:Pseudonym>

<fed:RelativeTo>

<wsa:Address>http://www.example.org/example-target-scope</wsa:Address>

</fed:RelativeTo>

<fed:SecurityToken>..</fed:SecurityToken>

<fed:ProofToken>...</fed:ProofToken>

</fed:Pseudonym>

</wsrt:Value>

</wsrt:Create>

</S:Body>

</S:Envelope>

Security Tokens and Pseudonyms

Pseudonyms services can associate a pseudonym with a security token. The requestor can storeand retrieve a security token that it receives from a Security Token Service, or the Security Token Service can store and retrieve the security token on behalf of the requestor. On the other hand, a requestor can communicate with a Security Token Service by sending a RequestSecurityToken element conforming to the WS-Trust specification, and receive a RequestSecurityTokenResponse element in return.

RequestSecurityToken and RequestSecurityTokenResponse Extensions

If a Security Token Service is mapping pseudonyms to present a unique pseudonym to a target service, security token requests can contain a fed:RequestPseudonym element in the RequestSecurityToken. The structure of the fed:RequestPseudonym element is as follows:

<fed:RequestPseudonym SingleUse="xs:boolean" Lookup="xs:boolean" ...>

...

</fed:RequestPseudonym>

The value of the SingleUse attribute is used to specify that a pseudonym shall be used only once. The value of the Lookup attributes specifies that a pseudonym associated with the scope that is indicated should be returned, or if the primary identity for the principal should be used regardless of the context. The RequestPseudonym element is extensible. Additional elements and attributes can be included in the RequestPseudonym element if they do not modify the semantics of the WS-Federation specification.

Security Tokens and RequestSsecurityToken and RequestSecurityTokenResponse Extensions

Pseudonym Services can also store usernames and passwords, symmetric keys and newly generated private keys along with the pseudonyms.

The ReferenceToken Element

Reference tokens are an extension to WS-Trust that were created as part of the WS-Federation specification. They enable RequestSecurityTokenResponse messages to return a reference to a token, secured with a proof token, leaving it up to the requestor to acquire the token itself.
The ReferenceToken element has the following structure:

<fed:ReferenceToken ...>

<fed:ReferenceEPR>wsa:EndpointReferenceType</fed:ReferenceEPR>

<fed:ReferenceDigest ...>xs:base64Binary</fed:ReferenceDigest>

<fed:ReferenceType ...>xs:anyURI</fed:ReferenceType>

<fed:SerialNo ...>...</fed:SerialNo>

...

</fed:ReferenceToken>

The ReferenceEPR element contains an endpoint reference that the request was sent to. The optional ReferenceDigest element contains an SHA1 digest of the token. The optional
ReferenceType element contains a URI that specifies the token type. The SerialNo element contains a unique identifier for the token. The ReferenceToken element is extensible. Additional elements and attributes are allowed in the ReferenceToken element, and additional attributes are allowed in the ReferenceDigest, ReferenceType and SerialNo elements if they do not modify the semantics of the WS-Federation specification.

The FederationID Element

The FederationID element can be included in an RequestSecurityToken or RequestSecurityTokenResponse in order to indicate which federation is being used. The structure of this element is as follows:

<fed:FederationID ...>xs:anyURI</fed:FederationID>

The FederationID element contains a URI that identifies the federation. The FederationID element is extensible. It can contian additional attributes that do not modify the semantics of the WS-Federation specification.

The RequestProofToken Element

The RequestProofToken element is used to extract a token to pass to a relying party that does not have the ability to get the session key. It has the following structure:

<fed:RequestProofToken ...>

...

</fed:RequestProofToken>

The RequestProofToken element is extensible. Additional elements and attributes can be
included in the RequestProofToken element if they do not modify the semantics
of the WS-Federation specification.

The ClientPseudonym Element

Pseudonym services may optionally support the ClientPseudonym element. The ClientPseudonym element is used to request an ad hoc pseudonym and is echoed in the RSTR. It has the following structure:

<fed:ClientPseudonym ...>

<fed:PPID ...>xs:string</fed:PPID>

<fed:DisplayName ...>xs:string</fed:DisplayName>

<fed:Email ...>xs:string</fed:Email>

...

</fed:ClientPseudonym>

The PPID element contains a private personal identifier. The DisplayName element
contains a display value. The Email element contains an E-mail address. The ClientPseudonym element is extensible. Additional elements and attributes can be included in the ClientPseudonym, PPID, DisplayName and Email elements if they do not modify the semantics of the WS-Federation specification.

The Freshness Element

The Freshness element is used to specify how long to re-use cached credentials. It has the
following structure:

<fed:Freshness AllowCache="xs:boolean" ...>

xs:unsignedint

</fed:Freshness>

The integer value of the Freshness element is used to specify the number of minutes to allow the re-use of cached credentials. The Freshness element is extensible. Additional attributes are allowed to be included in the Freshness element if they do not modify the semantics of the
WS-Federation specification.

Authorization in WS-Federation

One type of Security Token Service supported by WS-Federation is an authorization service.

WS-Federation includes an authorization model and extensions to the WS-Trust specification that are created for the purposes of supporting powerful authorization expressions. An authorization service uses two tables to make authorization decisions. The first of these tables is the requirement table that specifies the claims that are required to access target
services. The second table is the claim table and is used to store the sets of claims that requestors have provided, after processing with other context information and applicable policies.

The auth:AdditionalContext Element

The auth:AdditionalContext element is used for including arbitrary authorization context data in the RST and RSTR. It has the following structure:

<wst:RequestSecurityToken>

...

<auth:AdditionalContext ...>

<auth:ContextItem Name="xs:anyURI" Scope="xs:anyURI" ...>

element.</auth:AdditionalContext>

...

</wst:RequestSecurityToken>

The ContextItem element contains is used to specify names and values for additional context properties. The Name attribute value is a URI that indicates what type of context property is being specified. The Scope element is optional and is used to indicate a scope for the property.

A Dialect for Interoperable Claim Expression

A dialect is included in the WS-Federation specification for the interoperable specification of claims. A RequestSecurityToken element with a set of claims that uses this dialect has the following
structure:

<wst:RequestSecurityToken>

...

<wst:Claims Dialect=http://schemas.xmlsoap.org/ws/2006/12/authorization/authclaims>

<auth:ClaimType Uri="xs:anyURI" Optional="xs:boolean">

<auth:Value>...</auth:Value>

</auth:ClaimType>

</wst:Claims>

...

</wst:RequestSecurityToken>

The ClaimType element is used to specify an individual claim. The Uri attribute is used to indicate the claim type. The Optional attribute is used to specify whether a claim is optional or mandatory. The Value element is optional and is used to indicate a string value for the claimbeing specified. The ClaimType element is extensible. Additional elements and attributes are allowed to be contained in the ClaimType element if they do not modify the semantics of the WS-Federation specification.

SOA Security and HSPD-12: Cryptographic Foundations

2007-02-19T18:42:00.000-08:00

Cryptographic Foundations for Understanding HSPD-12 and FIPS 201 Compliance Requirements
Post Overview
• Brief Overview of FIPS 201
• Cryptographic Foundations and Standards for FIPS 201

Additional Publications in Support of FIPS 201
– NIST Interagency Report 7337 Personal Identity Verification Demonstration Summary
• Report summarizes the demonstration of commercially available products that support FIPS 201 and the accompanying special publications
– NIST 800-06 PIV Card to Reader Interoperability Guidelines
• Provides interoperability requirements for PIV card readers in the areas of
– Performance
– Communications
• Covers two types of card readers:
– Contact card readers
– Contactless card readers
• Covers both access use cases:
– Physical access
– Logical access.
• Requirements are for PIV readers designed to read end-point cards.

Cryptographic Foundations and Standards for FIPS 201
• Review of Cryptographic Objects in FIPS 201
• Cryptographic Foundations
• FIPS 201 Cryptographic Requirements
• FIPS 201 Certificate Status Information Requirements

Cryptographic Mechanisms Specified in FIPS 201
Asymmetric PIV authentication key
Card authentication key
Asymmetric digital signature key for signing documents and messages
Asymmetric key management key, supporting key establishment or key transport

Cryptographically Protected Objects in FIPS 201, SP 800-73 and SP 800-76
Authentication Information Stored on the PIV Card
The following objects on the PIV card are required to be digitally signed by FIPS 201 and SP 800-73:
– The CHUID
– Biometric information
– The SP 800-73 Security Object
– X.509 Public Key certificates

Public Key Cryptographic Algorithms For Digital Signatures
• Rivest-Shamir-Adelman (RSA)
• Elliptic Curve Cryptography Digital Signature Algorithm (ECC DSA)
Cryptographic Components used with RSA Public Key Encryption
• The following components must be used with RSA in order to be secure:
– A hashing algorithm
– A padding scheme

Rivest-Shamir-Adelman (RSA) Public Key Encryption Algorithm
• An algorithm invented in 1978 based on the difficulty of factoring large integers, which can be used for encryption and digital signatures
• The algorithm is based on a public key which comprises a number N which is the product of two large primes (referred to as the modulus) and another number which is relatively prime
• The algorithm produces a private key, which is the multiplicative inverse of the relatively prime number which is included in the public key which is extremely difficult to calculate
• It is widely believed that the private key is as difficult to as it is to factor the integer N, but it has not been proven to be as difficult

Secure Hash Algorithms (SHA) for RSA
• Because the RSA algorithm requires the use of a hash algorithm, a secure hash algorithm must be used along with RSA
• The SHA family is a set of related cryptographic hash functions that were designed by the National Security Agency
• SHA has two major subsets:
– SHA-1
• Published in 1995
• Was considered to be the successor to the widely used MD5 function
• Vulnerable to known attacks
– SHA-2 (including SHA-224, SHA-256, SHA-384 and SHA-512)
• No attacks have yet been reported
• Because they are similar to SHA-1 researchers are working on more secure hashing standards to use in the event that SHA-2 is compromised

Purpose of Padding Schemes in RSA
• RSA must be combined with a padding scheme for the following reasons:
– To increase message size in order to address the following problems that can occur in short messages:
• Values m=0 and m=1 produce ciphertexts equal to 0 or 1 because of the properties of exponentiation
• Ciphertexts can be easily decrypted by taking the eth root of the ciphertext if using low encryption exponents and small values of m
– To provide a non-deterministic mapping from plaintext to ciphertext in order to defend against chosen plaintext attacks, which deterministic encryption algorithms such as RSA are vulnerable to

Specific Padding Schemes Used for RSA
• Public Key Cryptographic Standard (PKCS) #1 v 1.5
• Padding based on the Probabilistic Signature Scheme (PSS)

PKCS (Public Key Cryptography Standards) #1 v1.5
• Specified in the Network Working Group RFC 2313, Mar. 1998
• The original PKCS #1 standard was subject to chosen and adaptive ciphertext attacks
• PKCS #1 was modified to specify a plaintext-aware padding scheme, meaning that an adversary cannot produce a valid ciphertext without actually knowing the underlying plaintext, which defends against chosen ciphertext attacks
• However, because PKCS #1 v1.5 contains ad hoc constructions, it has not until now been proven secure against adaptive ciphertext attacks according to RSA Laboratories, the holder of the patent for the RSA public key encryption algorithm
• Used by most current implementations of RSA, but not recommended for new applications, for which an Optimal Asymmetric Encryption Padding (OAEP) scheme is recommended

Probabilistic Signature Scheme (PSS)
• A provably secure way of creating signatures with RSA
• Uses hashing in a sophisticated way to tie the security of the signature scheme to the security of RSA
• This is based on the notion that a digital signature scheme is provably secure if its security can be tied closely to that of an underlying cryptographic primitive, in this case RSA
• Developed by Mihir Bellare and Phillip Rogaway in 1996

Cryptographic Components Required For using Elliptic Curve Based Public Key Encryption
• An algorithm based on the difficulty of the discrete logarithm problem for elliptic curve groups
• A hashing algorithm

Elliptic Curve Digital Signature Algorithm (ECDSA)
• A variant of the Digital Signature Algorithm (DSA) that operates on elliptic curve groups
• The discrete logarithm problem is expressed by the problem of solving the following equation where a and c are known:
• ab=c
• An elliptic curve is a plane curve defined by an equation of the form:
• y2=x3 + ax + b
• The solutions to this equation form a finite abelian group
• Elliptic curve cryptography is based on the difficulty of solving the discrete logarithm problem on an elliptic curve group, which is believed to be more difficult than the corresponding problem in the underlying finite field
• It therefore provides smaller key sizes for the same security level, with execution time and signature size exactly the same
• While no proof of the difficulty of ECC has been published as of 2006, it is recommended by the National Security Agency in its Suite B set of recommended algorithms for communication of data with classification levels up to TOP SECRET

Hash Algorithms for ECDSA
• Because Elliptic Curve Digital Signature Algorithm uses a hash function, hash algorithms are required just as they are in RSA
• SHA-224 and SHA-256 are examples of hash algorithms that can be used with ECDSA

Key Management Key Algorithms
The following algorithms are used for key management key management:
• Rivest-Shamir-Adelman (RSA)
• Elliptic Curve Diffie-Hellman (ECDH)
• Elliptic Curve Cryptography Menezes-Qu-Vanstone (ECC MQV)

Diffie-Hellman Key Exchange (foundation for ECDH)
• A cryptographic protocol that allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher.
• Because the parties involved are not known to each other it is known as an anonymous or non-authenticated key agreement protocol.
• It provides the basis for a variety of authenticated protocols and is used to provide perfect forward secrecy in Transport Layer Security (TLS)’s ephemeral modes.
• First published by Whitfield Diffie and Martin Hellman in 1976, although it was developed earlier by Malcolm J. Williamson of the British signals intelligence agency GCHQ, but was at that time classified.

How Diffie-Hellman Key Exchange Works
• An example:
• A and B agree to use a prime number p=23 and base g=5.
• A chooses a secret integer a=6, then sends B the value (g2 mod p) = 56 mod 23 = 8
• B chooses a secret integer b=15 and sends A the value (gb mod p) = 515 mod 23 = 19
• A computes the value (gb mod p)2 mod p = 196 mod 23 = 2, the shared secret
• B computes value (g2 mod p)b mod p = 815 mod 23 = 2, the shared secret
Both A and B have computed the same value because g2b and gb2 are equal. However computing the shared secret given g, p and g2 mod p cannot be done with the best known algorithms if p is a prime of 300 or more digits, and a and b are at least 100 digits long. This is known as the discrete logarithm problem.

Elliptic Curve Diffie-Hellman (ECDH)
• A key agreement protocol that allows two parties to establish a shared secret key over an insecure channel
• The key can be used to encrypt subsequent communications using a symmetric key cipher
• A variant of the Diffie-Hellman protocol using elliptic curve cryptography, which is based on a more complex version of the discrete logarithm problem allowing shorter key sizes for the same degree of security based on known algorithms
• Secure because nothing is disclosed other than the public keys, and extraction of the private key of one of the parties requires solution of the Elliptic Curve Discrete Logarithm Problem.

Elliptic Curve Cryptography Menezes-Qu-Vanstone (ECC MQV)
• An authentication protocol for key agreement (based on the Diffie-Hellman scheme) which was initially proposed in 1995
• Possibly the most efficient of all known authenticated Diffie-Hellman protocols that use public-key authentication
• Provides protection against an active attacker
• Has been shown by Hugo Krawczyk in June 2005 to be vulnerable to attacks in the Canetti-Krawczyk model of key exchange, which was acknowledged by Alfred Menezes in a proposed patch of ECC MQV called HMQV-1 in Nov. 2005
• Specified by the National Security Agency as part of the Suite B set of cryptographic standards for securing US Federal government communications up to the TOP SECRET classification

Algorithms for Card Management Keys
• Triple DEA
• Advanced Encryption Standard (AES)
DEA
• DEA is the Data Encryption Algorithm, also known as the Data Encryption Standard (DES)

Triple DEA
• Triple DEA is a block cipher formed from the DES cipher by using it three times
– Three steps are needed to prevent meet-in-the-middle attacks that are effective against double DES encryption
• Triple DEA requires keys that are 32 characters long and is ANSI standard for PIN management
– 2TDEA is Two Key Triple DEA
• A variant of 3TDEA that uses the same key as the first and third key, but is vulnerable to chosen-plaintext or known-plaintext attacks, giving it an effective security of 80 bits
– 3TDEA is Three Key Triple DEA
• Has a key length of 168 bits comprised of three 56-bit keys, with an effective security of 112 bits.

Advanced Encryption Standard (AES)
• AES, which is also known as Rijndael, is the Advanced Encryption Standard which is viewed as the natural successor to Triple DEA
– AES is around six times faster than TDEA
– AES provides a larger block size, potentially longer keys
– There are as of 2006 no known cryptanalytic attacks on AES, however there have been successful side channel attacks
– The following variants are used in FIPS 201, using the key sizes included in the variant name:
• AES-128
• AES-192
• AES-256

Advanced Encryption Standard (AES) Cipher
• AES operates on a 4x4 array of bytes, referred to as the state
• For encryption, each round of AES (except for the last round) is performed in four phases:
– 1: Each byte of the state is combined with the round key, each round key is derived from the cipher using a key schedule
– 2: Each byte is replaced with another using a lookup table, resulting in a non-linear substitution
– 3: Each row of the state is shifted cyclically a certain number of steps
– 4: The four bytes of each column are combined using a linear transformation
– The last round performs the first rounding step instead of the column combination

FIPS 201 Cryptographic Guidelines
• FIPS 201 Signature Algorithm and Key Size Requirements for PIV Information
• FIPS 201 Public Key Object Identifiers for PIV Key Types
• FIPS 201 Standards for Key Management
• FIPS 201 Hash Algorithm Standards for Message Digests in the NIST 800-73 Security Objects
• FIPS 201 Card Management Keys
• FIPS 201 Certificate Status Information
• Note: Guidelines listed in red are the ones that expire in 2010 due to the security level not being viewed as adequate beyond that date

FIPS 201 Signature Algorithm and Key Size Requirements for PIV Information
• Through 12/31/2010 the following are supported:
– RSA (1024, 2048 or 3072 bits), SHA-1 or SHA-256 hash algorithms, PKCS #1 v1.5 padding scheme
– RSA (1024, 2048 or 3072 bits), SHA-256 hash algorithm, PSS padding scheme
– ECDSA (Recommended Curves, 224-283 bits), SHA-1, SHA-224 or SHA-256 hash algorithms

• After 12/31/2010 the following are required:
– RSA (2048 or 3072 bits), SHA-256 hash algorithm, PKCS #1 v 1.5 padding scheme, PSS
– ECDSA (Recommended Curves, 224-283 bits), SHA-1, SHA-224 or SHA-256 hash algorithms

FIPS 201 Public Key Object Identifiers for PIV Key Types
• PIV Authentication Key, Card Authentication Key and Digital Signature Key may use the following asymmetric algorithms:
– RSA
• The Key Management Key may use the following asymmetric algorithms:
– RSA
– ECDH
– ECC MQV

FIPS 201 Hashing Algorithms for Message Digests in the SP 800-73 Security Objects
• Through 12/31/2010, SHA-1, SHA-224 or SHA-256 may be used
• After 12/31/2010, SHA-224 or SHA-256 may be used
• The specific formats for the Algorithm Object Identifiers are specified in SP 800-76

FIPS 201 PIV Card Management Keys
• PIV cards may support card activation by the card management system to support Card personalization Post-issuance card updates
• The algorithm and key-size requirements for Card Management Keys are:
– Through 12/31/2010, 2TDEA, 3TDEA, AES-128, AES-192 and AES-256 may be used
– After 12/31/2010, 3TDEA, AES-128, AES-192 and AES-256 must be used

FIPS 201 Certificate Status Information
• There are two formats for certificate status information used for the FIPS 201 functional component PIV Card Issuance and Management Subsystem
– X.509 Certificate Revocation Lists (CRLs)
– Online Certificate Status Protocol (OCSP) Status reponse messages

Certificate Revocation Lists
A Certificate Revocation is issued by a Certificate Authority (CA) that also issues X.509 Digital Certificates
A Certificate Revocation List is a list of certificate serial numbers representing certificates that have been revoked and should not be trusted, for one of the following reasons:
– Certificate was revoked by the Certificate Authority (CA)
– A temporary hold has been put on the certificate, possibly because the user believes the private key may have been compromised. The certificate can be later reinstated if the integrity of the private key has been re-established.

Online Certificate Status Protocol (OCSP)
– The Online Certificate Status Protocol is used for obtaining the revocation status of X.509 digital certificates
– Messages are encoded in ASN.1 and usually communicated using HTTP
– OCSP has the following advantages over CRLs:
– OCSP can provide more timely information regarding revocation status of a certificate
– OCSP removes the need for clients to retrieve the CRLs themselves, leading to less network traffic and better bandwidth management
– Clients do not need to parse CRLs themselves, saving client-side complexity
– An OCSP responder may implement billing mechanisms to pass the cost of validation transactions to the seller rather than the buyer
– Not subject to the unnecessary public exposure of CRLs (sometimes compared with credit card companies’ bad customer lists)
– Supports trusted chaining of OCSP requests between responders, allowing clients to communicate with a trusted responder to query an alternate responder, saving client-side complexity

Certificate Status Information Digital Signature Requirements
• Certificate status responses are required to be digitally signed to support authentication and integrity using the following standards, using algorithmic identifiers specified in SP 800-78:
– Through 12/31/2010, the following may be used:
• RSA (1024, 2048 or 3072 bits), SHA-1 or SHA-256 hash algorithms, PCKS #1 v1.5 padding scheme
• RSA (1024, 2048 or 3072 bits), SHA-256, PSS padding scheme
• ECDSA (Recommended Curves, 224-283 bits), SHA-224 or SHA-256 hash algorithms

– After 12/31/2010, the following are required:
• RSA (2048 or 3072 bits), SHA-1 or SHA-256 hash algorithms, PKCS #1 v1.5 or PSS padding scheme
• ECDSA (Recommended Curves, 224-283 bits), SHA-224 or SHA-256 hash algorithms

SOA Security, Identity 2.0 and Convergence

2007-02-12T20:41:00.001-08:00

The convergence occuring between SOA, Ubiquitous Computing, Grid Computing, the Semantic Web, and Agent-Based Computing is being mirrored in the identity management area. I think it's all part of the same convergence, but am not sure what it will all be called once it is univerally recognized.

In the U.S. Federal Government, there is convergence happening between the E-Authentication Initiative and the efforts to implement HSPD-12 that requires implementation of a common identification system for Federal employees and contractors. With the convergence between Shibboleth, an E-Authentication Federation certified open source platform, and OpenID, an open-source identity federation, the possibility of convergence between the Federal and private sector is presenting itself. In October 2006, Identity 2.0 players from Microsoft and SxipIdentity were engaged in vigorous debate in their blogs about the differences between Microsoft's CardSpace(TM) and OpenID. A crucial topic of this debate was the vulnerability of the OpenID protocol to phishing attacks, in which a malicious web site pretends to be a legitimate participating site but is really attempting to get users to give up personal information. On Feb. 5, 2007, an Apache Authentication Module for CardSpace was made available for download [35]. On Feb. 6, 2007, there was an announcement made by the four companies Microsoft, Verisign, SxipIdentity and JanRain that their organizations would be collaborating, and specifically that Microsoft would be supporting OpenID in its identity management products. On Feb. 7, 2007, online identity provider ClaimID made a change in strategy to become the OpenID provider of choice. On Feb. 9, 2007 a demonstration of OpenID and CardSpace interoperability was presented at the Microsoft RSA Conference.

Convergence

The first wave of convergence on the Internet resulted in the World Wide Web. It was based on the convergence of technologies that had been in existence for years, that converged as an emergent property of the elegant invention, the URI, which is as simple and profound as Einstein's famous equation. The URI, HTML and HTTP together resulted in a transformed global economy, and profoundly altered the relationship between people and information. This first wave was a revolution in the delivery of information, the surface of the World Wide Web and of the global economy.

There is a second wave of convergence happening and it is happening on multiple levels. One of the levels is based on the emergent properties of XML and it's simple extension, SOAP, added to the foundation of the World Wide Web. This wave is transforming the plumbing of the Web and the global economy by making the virtual organization possible. As the technological foundation becomes more simple, the real-world application of the technology becomes more fluid and powerful. Technology is moving toward the minimization of itself as a barrier to the performance and management of business transactions.

One of these levels of convergence is in identity management. Let's look at the nuts and bolts. First, let's take a tour of the ideas and tools behind the notion of Identity 2.0, looking at OpenID, SXIP/DIX, Microsoft's CardSpace, LID and ClaimID. Then we'll look at the tools being used to express identity information including FOAF, XFN, hCard and RDF/vCard.

Identity 2.0

Identity 2.0 is an identity management model that has been created to give online interaction the same properties as real work interaction. It has the goals of

1. Reducing the number of registration forms that users need to fill out, which will reduce the enormous cost and effort previously required to provision new users for Web resources.

2. Limiting the amount of extra navigation required by users in order for them to share identity information· reducing the need for users to access services in a deferred manner (that occurs when a user has to wait for an E-mail response before accessing a resource).

3. Eliminating the existing limits on the identity information that a user can share.

Identity 2.0 provides users with the online equivalent of a driver's licesnse or passport, but allows them to decide which information that they want to share with whom. The following are the central ideas in Identity 2.0:

1. It is user-centric rather than permission-centric.

2. It has a concept of identity as a declarative group of claims and can include things like phone number, E-mail address but also things like customer service history, interests, social relationships and other attributes not traditionally found in user profiles in previous identity models.

3. It has a decentralized trust model based on URL ownership rather than the previous trust model based on centralized identity providers.

There are a number of Identity 2.0 identity technologies. There are URL based identity technologies, where a user's identity is associated with a URL, including XRI/i-name and OpenID. There are also token based identity technologies, where a user's identity is associated with a token, including CardSpace, SXIP, Higgins and Liberty.

In Identity 2.0, reputation based on identity is a currency used to acquire trust relationships.

Doc Searls in [33] describes a view of the Creative Commons as Creator Relationship Management, and how Identity 2.0 ideas can make creative collaboration between trusted parties as frictionless as possible. Kim Cameron of Microsoft thinks this is a "whole new creater-consumer model" [34].

XRI

Now let's look at a new relative of the URI that is one of the tools, besides URIs and URLs, that are being used to express and manage identity information in Identity 2.0 technologies.

An XRI (eXtensible Resource Identifier) is a privacy-aware, portable and persistent identifier for a resource which can be a person, organization, application, or idea. XDI (XRI Data Interchange) provides the ability to leverage XRIs to exchange, reference and update data between entities and maintain data exchange relationships. XRIs come in several flavors, including i-names, i-numbers, and i-tags.

An i-name is an internet address for a person. It provides a lightweight and safe way to authenticate and provide personal data, keep that personal data up to date and keep it private. It is important not to associate an i-name as a means of authentication only. For example, by using an i-name to provide contact information, a person can make sending spam E-mails extremely difficult. Microsoft's Identity 2.0 guru Kim Cameron claims to have used an i-name for several years without receiving any spam. An i-name is like a domain name in that it can be reassigned to a different resource by the i-name's owner. Each i-name corresponds to a non-reassignable i-number. An example of an i-name is =Andrew.Wilson which resolves to the URL http://xri.net/=Andrew.Wilson.

An i-number is an identifier for a resource which could include a person, organization, or file, which is not ever reassigned or transferred. For as long as the resource is available on the network, it can be addressed using its i-number.

An i-tag is an extensible, author-verifiable, which gives the author control over the tag dictionary that the tag should be resolved with, and provides dictionary services with the ability to provide services for tag authors and searchers. One use for an i-tag is to associate license information with digital content.

An i-broker is a provider of i-names. The owner of the entity referred to by an i-name need only be known to the i-broker. Examples of i-brokers include http://www.2idi.com/, the first i-broker, and http://http://www.iwantmynamenow.com.

OpenID

OpenID is a distributed digital identity system, in which a user's identity is represented as a URL or XRI. Any server that runs the OpenID protocol can verify the user's identity, providing a secure single sign-on for users of multiple Internet sites. Users do not need new accounts for each site, they only need an account with a trusted site, referred to as an identity provider, idP, or i-broker, which provides sites that run the OpenID protocol with the user's identity information.

These OpenID enabled web sites are referred to as relying parties or RPs. The OpenID protocol does not require a specific authentication protocol. In order to support sites containing sensitive data such as account or transaction information, these sites need to rely on identity providers that require strong authentication such as X.509 digital certificates, which are based on strong encryption. OpenID is supported by organizations that include Wikipedia, Technorati, Verisign and Microsoft. OpenID works a little differently from the familiar username and password that most users are familiar with.

1. An OpenID-enabled relying party, the site that the user wants to use, will have a login form with a single text box for the user to type in an OpenID indentifier. The relying party requests an XRDS document, which is sometimes referred to as a Yadis document from the identity provider, which contains proof that the identity provider asserts that the user is the one identified in the XRDS document. There are two operational modes for OpenID, checkid_immediate and checkid_setup. In the checkid_immediate operational mode, the identity information is exchanged between the relying party and the identity provider as a background task, requiring no user intervention. In the checkid_setup operational mode, the user communicates with the identity provider using the same web browser that they are seeking to access the relying party web site with. Depending on the security policy of the identity provider and relying party, they may establish an associate handle, a type of shared secret, saved by the relying party. The most common implementation of the associate handle is as a Message Authentication Code (MAC) conforming to the RFC1750 recommendations.

2. If the user is not already logged in to the identity provider, it will typically ask the user for a password, and ask whether the user trusts the relying party to receive the user's identity information. If the answer is negative, then the relying party is informed that the request for authentication is being rejected, and the relying party will deny access to the user.

3. If the user provides the password and answers in the affirmative that the relying party is trusted to receive identity information, then the identity provider replies to the relying party with the user credential information in the form of an XRDS (Yadis) document. If the relying party and identity provider have a previously established shared secret, then that shared secret is used by the relying party to validate that the credential information came from the identity provider and not some other entity, and the relying party grants access to the user.

4. If the relying party and identity provider do not have a shared secret, another step is required, called check_authentication which is done to ensure that the identity information did come from the identity provider.

HMAC-SHA1 and HMAC-SHA256 are the supported as signature algorithms. The latter is recommended in the OpenID 2.0 specification, and would be required for usage by any U.S. Federal Government application since it is FIPS 180-2 compliant, which HMAC-SHA1 is not due to the vulnerability of the underlying SHA-1 algorithm.

Because the OpenID protocol works well with AJAX, it is possible for this entire brokered authentication process to occur without the user leaving the relying party web page, unlike the browser redirects involved in other Federated identity approaches such as the E-Authentication architecture.

Users can use one of four methods to express their identity in OpenID. They can present a URL that is under their own control, which could be a home page or blog, to which they have added OpenID tags. They can present a URL received by registering with an OpenID identity provider. They can use an i-name, which is a reassignable synonym for an i-number. Whether the user chooses to use an i-name or i-number when using an XRI to express their identity, there is an underlying, un-reassignable i-number, which ensures that the user's identity cannot be taken over the way a DNS name can be taken over.

There is an OpenID Attribute Exchange specification which is under development to extend the OpenID framework beyond authentication. This could be used to implement the standard Role Based Access Control (RBAC) security pattern, or even more sophisticated access control using security context specific or transaction specific authorizations.

A part of the convergence is happening is that OpenID has already absorbed two technologies, the Simple eXtensible Identity Protocol (SXIP) and the Digital Identity Exchange (DIX) into the OpenID 2.0 Specification.

SXIP/DIX

SXIP, like other URL based identity protocols, allows for a decentralized model of identity management. SXIP has two types of participating sites, homesites and membersites. A homesite provides users and other sites the ability to control the data that they release to other sites. In the common nomenclature for federated identity systems, a homesite is an identity provider. Membersites are consumers of identity data used to provide access to services. Membersites send user identity requests to homesites through the user's browser. Membersites can discover dynamically a user's identity without having an existing relationship with a homesite. The discovery service points to the homesite in SXIP rather than the user's identifier. SXIP supports the exchange of third party claims and reliable updates to identity information that has been provided to membersites. SXIP has a separation between the authority for an identity assertion and the release of that assertion, eliminating the need for a homesite to process assertions every time they are requested by membersites. The following steps occur when a user connects to a membersite for the first time using SXIP 2.0:

1. The user types a homesite path into the type-in field next to a button labeled "sxip in" on the membersite page.

2. The user's browser is redirected to the homesite, which prompts the user to enter login information.

3. The user enters a username and password, and is presented with a logo representing the membersite indicating that the membersite is requesing their identity data.

4. The user selects a Persona from a set of Persona that they have established on the homesiste, which is represented by a URL, and verifies that the information contained in the person is correct.

5. The user selects whether the data contained in their Persona will be automatically shared with the membersite whenever they visit it again.

6. The user confirms that their identity information can be released to the membersite.

7. The user's browser is redirected to the membersite.

8. The membersite grants access to the user.

Through the use of the Persona, SXIP provides the user with the ability to decide which information they want to share with membersites.

When a SXIP user accesses a membersite on subsequent visits, the following steps generally occur:

1. The membersite accesses a cookie identifying the user's homesite.

2. The membersite displays the homesite that the user has already authenticated with.

3. The user clicks the button labeled "sxip in", if they want to access the membersite using the homesite whose homesite path is displayed.

4. The membersite grants access to the user.

CardSpace

Windows CardSpace is an identity metasystem, a digital identity framework which allows transaction-based identity. It is a component of Microsoft's initiative to create an identity metasystem. CardSpace rests on a foundation of WS-Security, WS-Trust, WS-SecurityPolicy and WS-MetadataExchange, and will run on any platform that supports those standards. CardSpace is part of Windows Vista and is also included in the .NET Framework 3.0. It supports both self-issued and managed identities, similar to OpenID. In order to authenticate using a CardSpace managed identity, a Security Token Service must be used that generates signed, encrypted tokens conforming to the WS-Trust standard.

Identities are stored as InfoCards in CardSpace. InfoCards are the digital equivalent to the physical identification cards stored in many people's wallets. The following steps occur when a CardSpace user browses to an InfoCard authentication compatible resource.

1. A modal dialog appears giving the user a choice of which InfoCard to present to the site that is asking for authentication. Because the dialog is modal, it prevents the user from browsing to another site (perhaps a phishing site) until the authentication process has completed.

2. The user decides which InfoCard to present and selects it.

3. The CardSpace InfoCard manager presents the user's identity information to the site that is asking for authentication.

4. The site grants access to the user.

The principal impetus behind the convergence of OpenID and CardSpace is the privacy and anti-phishing support provided by CardSpace.

The Higgins Trust Framework

The Higgins Trust Framework is an open-source, cross-platform framework for exchanging identities. It is an identity card selector like Microsoft's CardSpace. It supports the exchange of profiles and social relationships as well. The Higgins framework is user-centric, and was created to empower users with control over their identities, relationships and personal data. Users, rather than others, are in control of their data in the Higgins framework, and can decide what information they want to divulge when to trusted systems of their choice. Being API based it supports both browsers and rich clients, and has been designed with an SOA approach. It originated with SocialPhysics.org and is supported by IBM and Novell. Within the framework, a Context consists of a set of Digital Subjects, each possessing a Contextually Unique Identifier (CUID), which itself is an Identity Attribute. Optionally, the context might also have a Security Policy. A Digital Subject is a set of Identity Attributes. A given entity, which can be a person, may have multiple identities represented as Digital Subjects within the same context, or spread across multiple contexts.

An I-Card is a visual presentation of a Digital Subject which contains identity information. Just as a person may have different identity cards for different social contexts if they so choose, an entity can have multiple I-Cards to be used for purposes of their choice, including authentication. An I-Card comes from an I-Card provider, which may be a CardSpace compatible managed or personal providers, or a URI managed or personal provider.

XDiggins is the convergence of the Higgins Trust Framework and XDI.

OpenID, Phishing, idproxy and CardSpace

idproxy is a tool created by to allow users to access OpenID relying parties using their Yahoo! credentials. It also provides two added protections against phishing attempts. One is that an idproxy user selects a "Monster" which will greet them by name when they log in to idproxy. Because of the unlikelihood of a would-be phisher guessing which monster the user selects, it provides an extra layer of protection. In addition, rather than redirecting users to a relying party site with a login page, idproxy users are expected to browse to idproxy.net rather than using a login form on a site that the user is redirected to. This is one solution to the OpenID phishing problem.

Another approach to solving the OpenID phishing problem was proposed by Charles Drake, which is to have an Identity Provider authorize by using the user's static IP address rather than by issuing a password request. He also notes that authenticating with a browser certificate would also suffice. In either instance, there is no need to provide secret information which can be used by an unfriendly relying party.

Gabe Wachob in [26] made an important assertion about OpenID that relates to the SOA concept of Sofware as a Service (SaaS), when he urged that there be a distinction made between projects that aim to provide innovative approaches to authentication, such as the examples he provides, Mozilla/Firefox, Microsoft CardSpace and VxVsolutions, and projects that aim to provide innovative online services. This mirrors exactly the movement toward independence between security services and business services in SOA.

Microsoft's Kim Cameron outlines how OpenID and CardSpace can be integrated in [27], by having the user login using an identity selection tool such as CardSpace, which being part of the Windows desktop would not be susceptible to phishing attacks. This has resulted in the interoperability support for OpenID and CardSpace.

Another tool that allows users to login using OpenID, i-names or CardSpace is Whobar.

LID

Light-Weight identity (LID) is a set of digital identity management protocols which is compatible with underlying protocols including OpenID and Yadis. It is a RESTful technology, operating completely within a user's browser. LID is used for services including single sign-on, message authentication, contact management, social networking and publishing information so that access is only granted to trusted entities. Cryptographic proof is used to establish identity using OpenID or GPG.

Yadis

Yadis is the underlying service discovery layer which is the foundation for OpenID, and is also supported by LID. It is a key to interoperability, allowing discovery for different types of identity expressions including i-names, OpenID URLs, LID Ids, or Sxip Ids. The following steps occur in a the service discover process in Yadis.

1. A Yadis ID is presented.

2. The determination is made whether the Yadis ID is an XRI (such as an i-name), URL or other type of token.

3. A Relying Party Agent makes an HTTP request using the Yadis ID, and obtains either a Yadis document or the URL for a Yadis document.

4. A Yadis Resource Descriptor is extracted from the Yadis document, which contains a description of services available and which services can authenticate a user.

SAML 2.0 Enhanced Client or Proxy Profile

The SAML 2.0 Enhanced Client or Proxy (ECP) profile provides a foundation for identity metasystems for SAML consumers such as Web services using the WS-Security SAML Authentication profile. This is a way for SAML to leverage the user-centric identity management ideas for Identity 2.0. The following steps occur in an access to a resource using the SAML 2.0 ECP.

1. The SAML Principal, using the ECP, issues an HTTP request to a Service Provider for gaining access to a protected resource, for which there has not been already established a security context for the Principal and ECP.

2. The Service Provider issues an Authentication Request to the ECP, which is then delivered by the ECP to an appropriate identity provider. The SAML Reverse SOAP (PAOS) binding is used for this.

3. The ECP retrieves the endpoint location to an identity provider.

4. The ECP passes the Authentication Request to the identity provider.

5. The identity provider retrieves identification of the Principal.

6. The identity provider sends a Response message to the ECP using the SAML SOAP binding.

7. The ECP passes the Response message to the Service Provider.

8. The Service Provider grants or denies access to the service.

Using this approach, Web services can be accessed using SAML 2.0 with user-controlled and managed identities or personal information.

For certificate-based authentication for Web services using the WS-Security X.509 Digital Certificate profile, a way for the user to manage and select digital certificates is needed.

RDF

The Semantic Web is being used as a foundation for many of the tools being used to manage personal data on the Web. The Resource Description Framework (RDF) language is used to represent information about resources. RDF is based on XML. Unlike most data represented in XML that is structured in a hierarchical tree format, RDF represents data that is stored as a graph, meaning that there can be cycles or loops in the data model. The uses of RDF are numerous. It is used to provide data that can be machine processed in contexts other than the original context that it was created for, with the intention of making the World Wide Web as accessible to computer programs such as spiders, agents and bots as it is to human users. It is used to provide Web metadata such as privacy preferences, content rating, descriptions of capabilities. It is used for applications that require open information models such as annotating Web resources, collaborative scheduling of activities, and collaborative process description. It is also used for combining data from multiple applications to create new information. RDF can be used for the purposes of representing identity and other personal data. RDF is used to associate information with a URI representing the entity being described. The information about the entity is expressed in one or more RDF vocabularies, using a namespaces identified by other URIs.

Now that we have looked at the emerging identity federation tools from an application-centric point of view, let's looks at the tools available for users to control their own personal information.

FOAF

Friend of a Friend (FOAF) is a collaborative RDF metadata vocabulary about people, relationships and interests, and can include image, contact and geographic metadata using properties and established RDF vocabularies. It can be used in applications such as contact databases, address books, virtual communities and organizational directories. From an identity management point of view, these are all identity attributes. FOAF enables users to create their Semantic Web home page equivalent. FOAF provides the ability for the user to publish E-mail address contact information encoded using the SHA-1 secure hash algorithm, using a property calles foaf:mbox_sha1sum. People are identified in FOAF using the OWL (Web Ontology Language) concept of an Inverse Functional Property (IFP). These IFPs include E-mail addresses and home page addresses. The foaf:depicts property is used to associate images with people.

Out of the box, FOAF allows other people to associate information with a person, so there is a need to validate whether the personal data was in fact provided by the person in question. In order to securely associate an author with an FOAF file, files are signed with digital signatures generated using the Pretty Good Privacy (PGP), which establishes a connection between the file and the owner of the private key corresponding to the public key used to validate the signature, and prevents tampering of the file by anyone who does not possess the private key. Users protect private FOAF information by encrypting the data with PGP, using the public keys of people or entities that they wish to make the private data available to. While FOAF empowers users with control over their own personal information, it requires hand crafting and requires encryption of private data for each intended recipient. There clearly is a need for the ability for non-HTML savvy users to make use of this kind of privacy protection, and a tool called FOAF-a-Matic has been created for this purpose. However, FOAF-a-Matic might be enhanced to include PGP signing and encryption in order to provide the ability for the general public user to take full advantage of the privacy protection available through the use of PGP with FOAF. Another enhancement that may be useful is the concept of privacy categories or levels. For example, a user might want to make certain information available only to specific entities, but might want to make other information available to members of some group. In a business situation a user may want to provide home or cell phone numbers and private E-mail addresses only to specific people, but provide work phone and E-mail to all members of the same organization, which could be a company, SIG, or professional organization such as IEEE or PMI. FOAFBot is a tool for spidering FOAF files for a community application (it was created to support IRC), which can leverage PGP to allow only a specific trusted organization to see private data for dissemination within that group.

XFN

The XTHML Friends Network (XFN) is a very simple, lightweight way for people to specify relationship information using HTML, XHTML or XML attributes. This information is intended to make sense to both humans and computers. For example, a user can specify a relationship in their blogroll by including a rel attribute such as this:

rel="contact"

There is also the ability to specify finer-grained relationship information:

rel="contact met"

The rel="me" attribute value is used to designate links to an individual's own personal data. While XFN can be used to link web resources from any HTML, XHTML or XML document, it's primary use is for blogrolls. In XFN, information is controlled by the author and there is no method of confirmation that relationships are two-way. While it does not have any integrity or privacy protection itself, XFN can be used in conjunction with FOAF to provide security for the user. The advantage of this for the user is the ability to specify finer-grained relationship information. Business uses for this technology can include tracking customer relationships and technical and professional contacts online.

hCard

hCard is a semantic XHTML format for representing the elements of the vCard specification. It is an open microformat standard which can be included in XHTML, HTML, Atom, RSS and XML formatted data. A vCard is a digital business card, and contains information such as name, address, E-mail addresses, telephone numbers, images, logos, audio clips and other information. The vCard specification is used in Apple's MacOS X address book.

vCard/RDF

vCard/RDF is another way users can control their personal information on the Semantic Web. The RDF vCard specification establishes a namespace which contains the property types and values that had been previously specified in the vCard specification.

There does not seem to be much consideration given to privacy in the vCard and vCard/RDF specifications, however. For this reason, while vCard was created as a business-centric specification, the privacy and integrity functionality of FOAF might make it seem a better choice.

Convergence

The company PingIdentity, who presented the demo of interoperability between OpenID and CardSpace an RSA show on Feb. 9, 2007, proposes an Identity Metasystem which allows an interoperable framework preserving the advangates of SAML, OpenID, CardSpace and WSF. They hope to see a convergence that eliminates duplication between the different protocols, without eliminating any of the unique value provided by each of them. In their view, SAML's advantages are in terms of robust privacy and security models, vendor interoperability and broad scope. CardSpace has the advantages as they see it of being part of the Windows desktop and the elimination of password management. For OpenID, they recognize a lightweight trust model as the default, simplicity and facile integration as advantages. Finally they feel that ID-WSF has the advantages of offline use cases, distributed identity services and a malleable security model.

References

[1] Connolly, Dan, A Look at Emerging Web Security Architectures from a Semantic Web Perspective, DRAFT in progress, 2006.
URL: http://www.w3.org/2006/03dc-aus-lga/swauth
[2] http://en.wikipedia.org/wiki/OpenID
[3] OpenID Authentication Specification 2.0, Draft 11, http://openid.net/specs/open-id-authentication-2_0-11.html
[4] PingIdentity.com, Internet Scale Identity Systems: An Overview and Comparison, Jan. 7, 2007,
http://www.pingidentity.com/InternetIdentity010707b.pdf
[5] http://www.w3c.org/p3p
[6] http://www.foaf-project.org/
[7] http://www.ldodds.com/foaf/foaf-a-matic.html
[8] http://usefulinc.com/foaf/foafbot/
[9] Dawson, F. and T. Howes, vCard MIME Directory Profile, RFC 2426, Sept. 1998 ftp://ftp.isi.edu/in-notes/rfc2426.txt
[10] Alden, Roland, et. al., vCard: The Electronic Business Card Version 2.1, 1996, http://www.imc.org/pdi/vcard-21.txt
[11] Representing vCard Objects in RDF/XML, W3C Note 22 February 2001, http://www.w3c.org/TR/vcard-rdf
[12] http://gmpg.org/xfn/
[13] Meyer, Eric. A., XFN and FOAF, GMPG, 2003-2007, http://www.gmpg.org/xfn/and/foaf[14] http://microformats.org/wiki/hcard
[15] http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/
[16] http://www.sxip.net/downloads/sxip2-overview.pdf
[17] Hinchecliffe, Dion, How Can We Best Make "The Writeable Web" A Responsible Place, SOA World Magazine, Jan. 23, 2006,
http://soa.sys-con.com/read/173822.htm
[18] Cote, Michael, Identity 2.0, Trustless Redirects, OpenID, LID, and Friends…or, Learning to Spell 'Centralized', blog entry,
http://www.redmonk.com/cote/2006/04/20/identity-20-trustless-redirects-openid-lid-and-friendsor-learning-to-spell-centralized
[19] Goodin, Dan, Web Services Security Standards Aren't Enough, InfoWorld, 11-24-2006, http://www.infoworld.com/article/06/11/24/48FEwssecstand_1.html
[20] Seely, Rich, SAML 2.0 meets Web 2.0, SearchWebServices.com, 29 Nov. 2006,
http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1232137,00.html?track=sy80
[21] Willison, Simon, Solving the OpenID Phishing Problem, blog entry, 1-19-2007,
http://simonwillison.net/2007/Jan/19/phishing/
[22] Laurie, Ben, OpenID: Phishing heaven, blog entry, 1/19/2007, http://www.links.org/?p=187
[23] Drake, Charles, A simple solution to OpenID phishing attacks, Digital Consumption, blog entry, 23 Jaun. 2007,
http://digitalconsumption.com/forum/A-simple-solution-to-OpenID-phishing-attacks
[24] Cameron, Kim, Identity Weblog, 20 Jan. 2007, http://www.identityblog.com/?p=657
[25] Cameron, Kim, Identity Weblog, 20 Jan. 2007, http://www.identityblog.com/?p=656
[26] Wachob, Gabe, Digital Identity and Beyond, Weblog
[27] Cameron, Kim, Integrating OpenID and InfoCard - Part 1, Identity Weblog, 21 Jan. 2007,
http://www.identityblog.com/?p=659
[28] Hardt, Dick, Whobar, 2006, Sxip Identity Corp., http://whobar.org/
[29] 2idi Help/FAQ, http://2idi.com/welcome/help
[30] Cameron, Kim, I-Cards and CardSpace, Identity Weblog, 1/26/2007, http://www.identityblog.com/?p=664
[31] Dale, Andy, The Tao of XDI, Weblog, 1/25/2007,
http://xditao.blogspot.com/2007/01/i-wrote-this-missive-in-email-thread.html
[32] Drummond, Reed, Mary Hodder, Andy Dale and Kaliya Hamlin, ed., I-Tag Specification Working Draft 03, April 2006, http://www.itags.net/index.php/I-Tag_Specification_Working_Draft_03
[33] Searls, Doc, Putting the Wholes Together, weblog, 2/5/2007, http://www.linuxjournal.com/node/1000180
[34] Cameron, Kim, Doc Searls on Creator Relationship Management, Identity Weblog, 5 Feb. 2007, http://www.identityblog.com/?p=667
[35] Jain, Aashish, Apache Authentication Module for CardSpace, weblog, Feb. 5, 2007, http://itickr.com/index.php/?p=56
[36] http://lid.netmesh.org/wiki/LID_Features_and_Benefits
[37] OASIS, Profiles for the OASIS Security Assertion Markup Language V2.0, 2005, http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

SOA Security and Secure Service Composition

2007-02-10T02:44:00.000-08:00

One security issue that arises in a Service Oriented Architecture that presents new challenges is the issue of secure service composition and secure service orchestration. A survey and discussion of current approaches to this problem are presented. Service composition can involve complex patterns of service interaction and also needs to assure conformance to non-functional or aspectual requirements including security policies and service level agreements (SLAs).

Bartoletti, Degano and Ferrari [1] have proposed an extended lambda-calculus with two primitives that represent the invocation of services that conform to certain security policies. These primitives are termed policy framings and are of two types, safety framings, by which a service protects itself from the service consumer, and liveness framings, by which a service consumer protects itself from the service. For motivation, they consider difficulties involved in service composition, or orchestration. One problem they pose is the composition of services from multiple providers that do not completely trust one another. The service needs to guarantee policy enforcement independent of the identity of the caller and for any operational interaction. The client, at the same time, must be able to protect sensitive data from unauthorized disclosure or tampering by the service. Their approach verifies policy framings using model-checking of over-approximations of all possible runtime program behaviors, which automates the established security practice of evaluating all possible program behaviors for security policy conformance. It does seem clear that secure service composition requires a corresponding security policy composition. The security policy composition may or may not satisfy the security policy required by the client. The conformance of the policy composition with the client required policy needs to be a requirement to be satisfied before selecting that service composition for invocation. Whether automatically accomplished based on semantics, or statically provided, a service composition's policy composition would be a prerequisite to determining that the service composition can provide a valid service level agreement to the client.

Sowell and Vitek [2] present an extended pi-calculus that expresses security policies as security wrappers, which are programs that control the interaction with trusted or untrusted components. They represent the possible information flows between components using a static type system. Within an SOA context, this would correspond to accomplishing a secure service composition by including a set of trusted and untrusted services along with security services that enforce the client's security requirements when calling the service composition. Untrusted services could be untrusted for not meeting specific security requirements such as authentication, authorization, message integrity, non-repudiation, etc., while possiblymeeting other specific security requiremtents. The function of the security services that operate as security wrappers would be to mitigate any defect in conformance with the security requirements of the client.

Gorla, Hennessy and Sassone [3] present the concept of a membrane, which consists of a security policy and a trust level of the source site of the agent. The membrane allows execution of an agent from a trusted site after validating a digest of the agent's behavior, while requiring full code checking of a mobile agent originating from an untrusted source. This model could be extended for SOA if the services in question were exposed to code checking by a code checking service, with the policy validation results made available to the client through a broker. Alternatively, rather than automated code checking, the broker could verify that a service has been verified by some authority as conforming to a published security policy.

The composition of services is a subset of program generation, and an important goal of Semantic Web services is the automatic composition of services based on semantics. This raises the question of how to perform the dynamic composition of services in a secure manner.

Bartoletti, Degano and Ferrari [4] approach the problem of service composition from the perspective of plan generation. They note a limitation of existing standards for service orchestration such as BPEL4WS as offering invocation of services only by names and signatures. They build on their previous work proposing service invocation by property [1], which could more readily be used to support the possibility of dynamic service creation, modification and withdrawl. Instead of considering the static service composition problem, they consider the service composition problem as a plan creation problem. They consider plans of three types, simple plans with a one-to-one mapping of service to request, multi-choice plans that map requests onto sets of services, and dependent plans in which the selection of a service depends on previous choices. They apply the same extended lambda-calculus approach they used to address the problem of static secure service composition to this problem. They introduce the idea of linearization to permit the validation of plans which will not allow the action of a particular service to violate a policy that would become in effect after the operation of that service in the execution of the plan. For multi-choice plans, they use a saturation approach to validate all possible execution paths. These multi-choice plans allow a service composition to operate even if component services became unavailable at runtime.

Bartoletti, Degano and Ferrari extend their approach to consider additional types of plans in [5]. These types of plans include dependent multi-choice plans, which are a combination of the previously considered multi-choice plans and dependent plans. The next two types of plans extend the expressive power of their approach to address orchestration scenarios. Regular plans are plans in which regular expressions are used to express possible service invocation patterns. Dynamic plans are plans that are updated at run-time based on the results of evaluation on program execution conditions. They apply their work on static validation of these plan types to develop the concept of the trusted orchestrator. The trusted orchestrator will provide clients with plans that always satisfy security requirements. They assert their approach can work even if the clients and services are all untrusted, where the orchestrator is the only trusted entity in the network.

Grimm et. al. [6] approach the problem of secure service composition from a dynamic content perspective. Motivated by the fact that dynamic content via mashups are easy to build but do not scale well. They propose a scalable, extensible and secure platform that is near client systems, supports mixing and mashing and hosts controlled code. They propose an architecture where static content caching and dynamic content script execution are provided on edge servers that DNS redirects users to. This platform is termed an open edge-side computing network. Services are implemented as scripts in their environment, and security policies are expressed using the same code constructs as the services are, allowing extensibility of the security policies. The approach also ensures that security policy enforcement is an integral component of service processing. Services are isolated from one another and resources are allocated based on overall system bandwidth consumption. The services are implemented as event handlers and linked together in pipelines. Services are implemented in a standardized way with every service containing administrative control components that can be redeployed across the network in order to protect against new exploits or threats. While their architecture is intended specifically for dynamic content producers and consumers in organizations with limited resources, using light-weight scripts, the approach of hosting services close to the users along with static content caching might have wider applications. Edge-side computing networks might be used to host services that processed more complex transactions and data. Services could be load-balanced on the network based on geographically-based demand. Service capacity levels for services with different peak load times would migrate based on demand. This approach could be implemented by large organizations such as global corporations or the U.S. Federal Government. Security services would follow the same pattern, based on demand and policy conformance. The same service at one peak load time or geographical location may have a different mix of security policy levels than at different peak load times or geographical locations. For example user in Wi-Fi hotspots might require different security policies than users of dialup or high-speed Internet connections. The same approach of being able to dynamically update security services across the network in response to new exploits or threats would provide the ability to dynamically alter the security posture for one or more virtual organizations.

Gu, Nahrstedt and Yu [7] address the issue of secure service composition in service-oriented peer-to-peer systems. The security challenges that they are facing are the requirement of decentralization and the dynamic nature of peer arrivals and departures, and focus on fault tolerance and quality of service as security concerns. When services start, a composition probing protocol is applied to delivery service composition meeting quality and resource usage requirements. Their approach uses backup compositions to handle fault tolerance, and supports changeable orders within compositions in which services are connected using directed acyclic graphs, in application domains including pervasive content distribution and collaborative scientific computation. They propose a peer-to-peer service overlay where services such as format translation of media files, data filtering and routing are provided by peers. The security advantages noted are the ability to avoid mobile code. Service compositions are created using these service overlays based on quality of service requirements. A composite service request consists of a function graph and a set of quality of service requirements. Their future directions include introducing distributed trust management to their approach. Their approach seems to be amenable to enhancing the composition request to include a security policy component along with the quality of service requirements. The backup composition approach seems to have wide applicability to other kinds of SOA applications such as supply chain processing, ubiquitous computing and VOIP. Backup compositions could be activated not only if services become unavailable but if they fall below quality of service levels provided by alternate services or their security credentials are revoked.

Bharadwaj and Mukhopadhyay [8] describe an approach using formal methods to develop discovery and composition of Web services that use an agent-based approach to meet security, situation-awareness and survivability requirements. Autonomous agents termed situation-aware ambients are responsible for discovering and composing services in response to situation changes. They argue that intelligent software agents provide the best foundation for dependability and security in distributed systems.

Hutter and Volkamer [9] present an approach to securing Web service composition using the Semantic Web as a foundation. They stress an approach of security the information flow as opposed to the standard access control approach to securing services. They note that Trojan horses and other hidden-channel-based information leakage can occur even if access control is implemented. They outline two major problems with an access control based approach. The first is that there are no standardized security labels for data or services since there is no authority to establish them. The result is that clients and services have their own interpretations of how data is to be processed. There must be a dynamic composition of security policies to go along with the dynamic composition of services. The second problem they outline with access control is that the dynamic composition of web services will result in the dynamic composition of data types that will need to have dynamic determination of security requirements for the handling of the data. Their approach associates type information with data in order to represent security requirements such as confidentiality. Using their approach, Web services can only process data if they conform to the security requirements for processing the data. Their approach leverages previous research in Artificial Intelligence in the area of planning in order to dynamically generate service compositions. Compositions are allowed if the data security categories and service security policies match. They use a type calculus approach to provide services with the ability to prove whether they will violate security policy requirements. The approach treats services as external procedure calls for the purposes of code security analysis.

[1] Bartoletti, Massimo, Pieraolo Degano and Gian Luigi Ferrari, Enforcing Secure Service Composition, Proceedings of the 18th Computer Security Foundations Workshop (CSFW), 2005.
[2] Sowell, P. and J. Vitek, Secure Composition of Untrusted Code, Box-Pi,Wrappers and Causality Types. Journal of Computer Security, 11(2), 2003.
[3] Gorla, D., M. Hennessy and V. Sassone. Security Policies as Membranes in Systems for Global Computing. Foundations of Global Ubiquitous ComputingWorkshop, 2004.
[4] Bartoletti, Massimo, Pieraolo Degano and Gian Luigi Ferrari, Plans for Service Composition, Workshop on Issues in the Theory of Security (WITS),2006.
[5] Bartoletti, Massimo, Pieraolo Degano and Gian Luigi Ferrari, Security Issues in Service Composition, Invited Talk at FMOODS 2006.
[6] Grimm, Robert, Guy Lichtman, Nikolaos Michalkis, Amos Elliston, Adam Kravetz, Jonathan Miller and Sajid Raza, Na Kika: Secure Service Execution and Composition in an Open Edge-Side Computing Network, Proceedings of the 3rd USENIX Symposium on Networked Systems Design and Implementation, pp. 169-182, San Jose California, May 2006
[7] Gu, Xiaohui, Klara Nahrstedt and Bin Yu, SpiderNet: An Integrated Peer-to-Peer Service Composition Network, 13th IEEE InternationalSymposium on High-Performance Distributed Computing, 2004.
[8] Bharadwaj, Ramesh and Supratik Mikhopadhyay, Position Paper:Formal Methods for Developing Adaptable, Secure, Situation-AwareService-Oriented Architectures, Workshop on Web Services Semantics,14th International World Wide Web Conference, 2005.
[9] Hutter, Dieter and Melanie Volkamer, Information Flow Controlto Secure Dynamic Web Service Composition, Proceedings of the 3rdInternational Conference on Security in Pervasive Computing, SPC-2006,Springer-Verlag, LNCS 3934, 2006.

SOA Security and Grid Computing

2007-02-06T00:14:00.000-08:00

Grid computing and Service Oriented Architecture are related branches of the field of distributed computing. SOA and the Grid Computing model share an important foundation: that of Web services technology. Like the synergy possible between an enterprise security infrastructure and a Service Oriented Architecture, there are benefits to be gained from SOA and Grid Computing sharing developments in security research.

My former employer W. Daniel Hillis, inventor of the connection machine, had a vision of computing as a service, like the electrical grid. This idea actually goes back at least as far as 1965 as one of the ideas behind the Multics operating system at MIT. For tasks demanding large amounts of computing resources, users would tap into the computing service and pay a metered amount for the service. The Grid computing model is a concrete realization of this vision, allowing networks of cheap commodity general purpose computers to work together. It brings the computing power formerly available only to users of massively parallel supercomputers to communities who agree to share computing resources.

Now, instead of buying time on a supercomputer a user with a large-scale computation task can enter into a service-level agreement (SLA) in a grid environment, temporarily allocating resources to build a virtual computer that will only exist for the duration of that computing task. Large data sets and computation tasks are spread across the grid by breaking them up into smaller tasks using parallel processing techniques. By taking advantage of this environment a user can often complete a large-scale computation task in a fraction of the time it would take on a single computer, for a fraction of the cost required for the user to own that amount of computing power. At the end of my street a company called ZipCar has cars that can be used by any ZipCar customer, allowing the customer to pay only for the time that they need to use the car, which could even be for an hour. The Grid provides large-scale computation power in a similar fashion.

The three properties that are generally used to define Grid computing each have their own security implications. These properties are the use of shared resources, open standards and service-level agreements. Shared resources are used to provide resource virtualization, dynamic provisioning of resources. Because the resources are generally shared between organizational units or organizations, they are subject to distributed administration. This requires the dynamic provisioning of security domains, referred to as virtual organizations. Virtual organizations exist in the SOA world in order to support outsource, insourcing, offshoring and virtual supply chains. For this reason security work done in the areas of Grid computing and SOA to support virtual organizations can be useful to both of these flavors of distributed computing. The fact that Grid computing uses open standards requires the use of security built on open standards, which are some of the same open standards found in the SOA world, including the WS-Security suite of standards. The use of service-level agreements in Grid computing requires a security infrastructure that can guarantee service levels, making availability a key security concern in the same way that it is found to be for SOA.

Demchenko [1] considers the vulnerabilities that the usage of Web services can expose Grid environments to. These vulnerabilities include the same Web services threats that SOA Security must address. He points out the vulnerability to "White Collar" attacks in which the attacker has an interest in the smooth operation of services in order to make detection difficult.

Ou et. al. [2] consider the topic of authorization in Grid environments and explicitly discuss the convergence of Grid computing with SOA. They point out authorization decisions within a Virtual Organization (VO) may require information that is located in multiple security domains. For this reason, authorization policies have to be able to access mulitple trust relationships between the atomic security domains that contain the user authorization information. Large enterprises such as the U.S. Federal Government are running into similar problems, where users need to participate in multiple security contexts, which may currently require the user to be in a different Virtual Private Network (VPN) in order to access services in each different security domain. The ability to dynamically provision a virtual security context spanning multiple security domains, based on trust relationships between those domains, is therefore an issue for SOA in these large enterprises. Ou et. al. [2] also notice a trend in Grid computing where it is necessary to distinguish between a Resource Provider and a Service Provider, where a Resource Provider delivers up computing resources and a Service Provider delivers specific computing services. In the SOA world this is analogous to the situation where an organization may want to access a service which is provided by another organization, which is hosted by yet another organization, to form a virtual organization for the duration of a business transaction or contractualrelationship. Ou et. al. [2] conclude that attribute based authorization through "science gateways" can beused to provide an interoperable authorization framework for a Grid environment. For an SOA in a large enterprise such as the U.S. Federal Government, this could be accomplished by providing Role Based Access Control (RBAC) as a service that could be consumed by multiple security domains in an interoperable manner, similar to the way the Credential Services are used to provide authentication in the existing Federal E-Authentication federation.

Periorellis et. al. [3] describe a project in which they seek to develop technology to support the creation, operation, and dissolution of virtual organizations. In order for organizations to cooperate in order to form virtual organizations, there must exist common standards by which these organizations can implementsecurity services including authentication, authorization, contract managment and monitoring. For authentication they are supporting the X.509 certificate, username token and a SAML assertions using WS-Security. Policies regarding authentication requirements are implemented using WS-Policy and WS-PolicyAttachment in their project. They leverage WS-Trust to implement trust brokering. In theirconsideration of Authorization they first note that dynamic virtual organizations require the dynamic activation and deactivation of access rights. They also note a requirement that user access be dependent on the context of the user's participation in a business process or workflow. This leads them to require that dynamic access control implement an additional level of granularity beyond the standard Role-Based Access Control (RBAC) model. This granularity is used to implement access control on a per-project orper-task basis. In their approach, contract monitoring can modify access rights for users based on the adherence to the contractual agreements. They use XACML (eXtensible Access Control Markup Language) to represent these fine grained authorization attributes. This allows the combination of sets of policies and rules at a Policy Decision Point to propagate decisions to a Policy Enforcement Point to allow or deny access based on dynamically changing policies used to implement the temporary security context of a virtual organization. While the frequency of VO creation and dissolution can not normally be expected to be as high in an SOA as it might be in a Grid environment, their findings may be used within SOAs to support thesein a more cost effective manner than approaches which express policies statically. In addition, specific business processes such as audits or investigations may be facilitated by dynamic VO creation in an SOA environment.

Fang et. al. [4] consider the problems of using Web Services Security in a Grid environment. They note that the processing of XML and digital signature verification required to implement WS-Security consumes a high enough level of system resources to consititute a Denial of Service attack vulnerability. Theypropose locating the WS-Security processing in a grid provides load balancing and scalability independent of application level services. They also consider the question of asynchronous vs. synchronous messaging styles and note that asynchronous messaging is preferable because of the ability to process a higher number of requests at peak processing times. This brings up an opportunity for SOA to take advantage of the Grid approach. The scalability inherent in their approach would be useful in an SOA environment because the dynamic allocation of resources for WS-Security processing would, given available resources, be able to handle the processing requirements of deploying more computationally intensive policies, for example requiringlarger key sizes, with minimal impact on overall service levels because the WS-Security processing would be load-balanced along with application level processing. Servers could then be incrementally added to the grid as needed.

In summary, a review of security research in the Grid computing field turns up common problems that occur in the SOA field and the potential for both fields to gain from sharing solutions to common problems, and indeed some are seeing a convergence between Grid computing and SOA in the area of security.

[1] Demchenko, Yuri, "White Collar" Attacks on Web Services and Grids, Work in Progress, Draft Version 0.3, March 14, Advanced Research Group, Univ. of Amsterdam, 2005
[2] Ou, Xinming, Anna Squicciarini, Sebastien Goasguen and Elisa Bertino, Authorization Strategies for Virtualized Environments in Grid Computing Systems, In IEEE Workshop on Web Services Security (WSSS 2006), Berkeley, CA, U.S.A., May, 2006.
[3] Periorellis, Panayiotis, J. Wu and P. Watson, Security Mechanisms for Data Intensive Systems, In IEEE Workshop on Web Services Security (WSSS 2006), Berkeley, CA, U.S.A., May, 2006.
[4] Fang, Liang, Aleksander Slominski and Dennis Gannon, Web Services Security and Load Balancing in a Grid Environment, submitted to 6th IEEE/ACM International Workshop on Grid Computing, 2005

SOA Security and Denial of Service Attacks on Trust Management Systems

2007-02-04T21:17:00.000-08:00

Trust management systems are an important component of identity management for enterprises and federated identity management for virtual enterprises. There exists a specific type of Denial of Service attack against Trust Management systems that must be carefully considered in the realm of SOA Security. Trust Management systems depend on the use of Digital Signature verifications that are used to validate credentials, which can occur in a trust chain of credentials.

A Denial of Service attack that is directed against a Trust Management system sends a request containing a long forged credential chain which is intended to force the target server to consume resources in validating the chain. While client puzzles (Aura et al) (Dean and Stubblefield) and an iterative approach to authentication (Meadows), with a quick initial first pass that is weak followed by a strong authentication pass, can be used to mitigate these attacks, Li et al show that credential caching can be used as a defense technique in this type of attack, coupled with a strategy that validates the credentials in the chain in a random order to make it difficult for the attacker to send a credential chain that will take the maximum amount of resources for the target server to validate. Their conclusion that the use of credential caching in conjunction with client puzzles would provide the most robust protection against Denial of Service attacks against Trust Management Systems is certainly persuasive.

Li et al also point out performance advantages of credential caching. Credential caching in Trust Management Systems provide performance advantages even if there are no Denial of Service attacks because the verification of a new credential requires only one additional signature verification. A unique aspect of credential caching as a Denial of Service defense is that the legitimate users actually participate in the defense, since the more legitimate users the server provides service to, the better the performance of the server in defending against attacks. Credential caching also has the advantage of allowing a server to have a longer maximum credential chain length. They also recognize the fact that the caching mechanism must provide credential expiration and revocation functionality.

References

Li, Jiangtao, Ninghui Li, XiaoFeng Wang and Ting Yu, Denial of Service Attacks and Defenses in Decentralized Trust Management, Proceedings of 2nd IEEE International Conference on Security and Privacy in Communication Networks, August 2006
Aura, T., P. Nikander and J. Leiwo, DoS-Resistant Authentication with Client Puzzles, Proceedings of the Cambridge Security Protocols Workshop 2000, Lecture Notes in Computer Science, Spring-Verlag, 2000.
Dean, D. and A. Stubblefield, Using Client Puzzles to Protect TLS, Proceedings of the 10th USENIX Security Symposium. USNIX, August 2001.
Meadows, C. A Cost-Based Framework for Analysis of Denial of Service Networks, Journal of Computer Security, 9:143-164, 2001.

SOA Security and Denial of Service Attacks

2007-02-04T20:19:00.000-08:00

SOA Security and Denial of Service Attacks

An approach to SOA security must consider one of the most difficult security problems faced by IT, the Denial of Service attack. This section will describe the current state of Denial of Service attack prevention and mitigation, and then outline how to apply this to securing an SOA. It will illustrate how SOA Security needs to encompass Web Services security techniques in addition to the existing security infrastructure of an enterprise to provide a comprehensive solution. An aspect oriented approach to SOA allows independent development of security and Quality of Service (Qos) aspects of an enterprise IT architecture, leaving business process aspects of the architecture to be developed and deployed on an independent basis as long as a simple set of standards are followed across the enterprise.

A Denial of Service (DOS) attack is intended to block the availability of a computing resource from the legitimate users of that resource. Common targets of this type of attack include web servers that have a high profile. The goal of the attack is to make Internet usage of the target web pages impossible. This type of attack is a computer crime and violates the Internet Architecture Board’s Internet proper use policy.

Two types of Denial of Service attack are generally encountered: One type of Denial of Service attack attempts to cause the target system to consume resources at a level that prevents users from accessing the service provided by the system. Another type of Denial of Service attack attempts to prevent communication between the users and the target system. A Denial of Service attack can also be a component of a larger attack strategy.

Examples of Denial of Service attacks include: attempts to prevent access to a system by sending more requests than the system can handle, attempts to prevent access to a system by flooding the network that the system is hosted on, attempts to block access to a service for a particular user and attempts to eliminate service to a specific system.

Denial of Service attacks can be directed at a number of specific devices or networks. Attacks can target routers, web servers, web services, mail servers or Domain Name System (DNS) servers. Three basic kinds of Denial of Service attacks are: causing a system to consume resources, including memory, network bandwidth, CPU time or disk space, disrupting a system’s configuration such as routing information, or disrupting the physical network that a service depends upon.

Symptoms of a Denial of Service attack include the unavailability of either any Web site or a particular Web site, slow network performance, and an increased level of spam E-mails.

The SYN Flood Denial of Service Attack

The SYN Flood attack floods a network with TCP/SYN packets, generally using forged sender addresses. What happens is that when one of these packets is received by the target system, it is handled as a connection request, causing the server to create a half-open connection. The target server sends back a TCP/SYN-ACK packet and waits for the corresponding TCP/ACK packet that would normally come back from the sender address. The resulting half-open connections will each consume an amount of resources on the target server, eventually reaching the server’s capacity for connection requests and preventing new users from successfully accessing the target system.

A TCP/IP connection is the most common Internet connection. The normal sequence of events is that a client system will send a TCP/SYN packet, indicating that the client system would like to connect to the server. The server sends back a TCP/SYN-ACK packet as its response, indicating to the client system that it may connect, and reserves a memory space for the client’s connection. The client then responds with a TCP/ACK packet specifying the details of the connection. In a SYN flood the client’s address is usually forged. The TCP/SYN-ACK response packet from the target server will be sent to a system that did not issue the original TCP/SYN request, and consequently the system whose address was forged will simply ignore the TCP/SYN-ACK packet, or it will go to a non-existent server. The resulting dead connection will consume resources on the target server. If enough of these requests are made for connections that are never completed, legitimate users are blocked from accessing the target system.

Other types of attack include the LAND attack, the ICMP Flood attack, the UDP Flood attack, Teardrop attacks and Application Level Flood attacks.. The LAND attack is a variation on the SYN Flood attack where the forged source address of the TCP/SYN packet is the address of the target system. This results in the target system responding to itself, and can cause the system to crash. The ICMP Flood attack, also called a ping flood, ping of death or smurf attack, is another variation of a flooding Denial of Service attack. This attack takes advantage of a misconfiguration of network devices that can allow packets to be sent to all systems on the network, using the network’s broadcast address. This type of network, when used in this type of attack, is referred to as a smurf amplifier. The attacker sends a large number of IP packets that have the source address of the target system. In order to prevent this type of attack, a Smurf Amplifier Registry is used to filter network traffic. A ping flood attack is accomplished by sending the target system a large number of ping packets. Blocking access to ping to the Internet is generally used to combat this type of attack. In a UDP Flood attack, also referred to as a Fraggle attack, the attacker floods the target system by sending a large amount of UDP echo traffic to IP broadcast addresses, using forged source addresses. It is very similar to the smurf attack.
In a Teardrop attack, an attacker sends IP fragments that have overlapping payloads to the target machine. This takes advantage of a bug in the TCP/IP code that reassembles IP fragements that results in a crash of the target system’s operating system. Versions of Windows up to Windows NT and Linux up to 2.0.32 and 2.1.63 are vulnerable to this type of Denial of Service attack. Application Level Floods take advantage of exploits including buffer overflow to consume resources on the target system, and are normally mitigated in an SOA by the application of WS-Security and OS level security design patterns and security patterns or best practices.

One may legitimately wonder what how SOA is any different than previous architectures in respect to Denial of Service attacks. Existing firewalls and intrusion detection devices are successully being used to block Denial of Service attacks launched from a single attacking system. It is in the realm of Distributed Denial of Service attacks that we will begin to see how an SOA approach can be combined with the approaches being developed to combat Distributed Denial of Service attacks and provide an integrated defense.

Distributed Denial of Service Attacks

A Distributed Denial of Service attack uses a botnet to launch a Denial of Service attack from multiple attack clients. If these attackers are compromised systems themselves, they are referred to as zombies. This type of attack prevents the simple blocking of an attacker’s IP address in the firewall that protects the target system as a solution.

A pulsing zombie attack is a Distributed Denial of Service attack that uses zombies to degrade system performance, on a recurring basis making it difficult to identify the set of source IP addresses that are controlled by the attacker and distinguish them from the IP addresses of legitimate users. If the set of source IP addresses of the attacking systems can be identified then the firwall protecting the target system can be used to block requests from that set of IP addresses.

Mitigation of Distributed Denial of Service Attacks

There are several main approaches to Distributed Denial of Service prevention. They are reactive approaches that operate after clients have attempted to access systems, and proactive approaches, requiring clients to perform actions before connecting to the target system.

Reactive approaches to Distributed Denial of Service include pushback, traceback and filtering.

The pushback approach uses routers to limit the amount of traffic flow from a set of client IP addresses sharing some particular property, such as the subnet address. The filtering is then pushed upstream in the direction of the source of the traffic, eliminating the impact of the traffic on downstream systems. Difficulties of this approach are the problem of identifying attack traffic, cooperation between ISPs and the fact that it requires routers to change state in order to accomplish the pushback of the traffic filtering.

The traceback approach focuses on the identification of the origins of the attack. Variants include traceback based on the Probabilistic Packet Marking Scheme and Hash-Based Traceback. The goal is to differentiate between attack traffic and legitimate traffic by generating attack signatures. This approach will not work if the attack traffic is coming from genuine source addresses or if the attack traffic is statistically similar to legitimate traffic. Traceback approaches also have scalability issues. The Probabilistic Packet Marking Scheme involves the probabilistic marking of each packet with partial path information. If a significant amount of traffic is received from the same source IP the attack target system will be able to reconstruct the path to the source from the collected set of partial path information. Hash-based traceback uses a packet digest store in the form of a Bloom filter at each router. The attack path can then be reconstructed by checking neighboring routers with attack packets.

Filtering approaches include Secure Overlay Services, Distributed Packet Filtering, the Pi Marking Scheme, and the Stateless Internet Flow Filter. Mayday is an approach using the Secure Overlay Services (SOS) architecture to defend against Denial of Service attacks in a proactive manner. Distributed Packet Filtering (DPF) takes advantage of BGP routing information to detect spoofed IP addresses in client traffic. The Pi marking scheme is another approach of detecting spoofed IP addresses. The Stateless Internet Flow Filter (SIFF) approach allows a target system to block traffic flows from specific sources without requiring the network to store per-flow state information, and provides a defense against bandwidth flooding attacks. Both Pi and SIFF require the ability to distinguish between legitimate traffic and attack traffic.

The critical problem facing reactive approaches is the difficult task of differentiating legitimate user traffic from attack traffic. Because of the difficulty of this task, reactive approaches result in non-zero false positive rates, blocking legitimate users from accessing systems, which results in an unintended Denial of Service attack on those users. For many applications this is an unacceptable situation. An SOA approach allows the insertion of gateway services between clients and services that deliberately introduce properties of the underlying IP packets that enable the unequivocal differentiation of legitimate user traffic, without allowing attackers to take advantage of this by intercepting and analyzing a sample of legitimate traffic flow. An attacker following this approach would result in a detectable change in the probability distribution of legitimate user traffic and allow the identification of which subset of identification properties had been compromised. The gateway services could then be dynamically updated with new security policies that would block access from attack traffic. One approach to this would be to distribute to clients a set of message attribute values to select on a random basis for each connection request. If the traffic is all from legitimate users then the message attribute values will arrive in a Poisson probability distribution. If an attacker intercepts one or more clients then the traffic’s distribution will be affected, thereby detecting the attack and triggering secure distribution of a new set of attribute values to the clients.

The Client Puzzle is the main proactive approach to Distributed Denial of Service attack prevention. A Client Puzzle requires the client system to perform an action that consumes a significant amount of client resources, balancing the field between the server’s resources and the resources of client systems that are requesting connections. Client puzzles can require the client system to perform a task, or perform the user to perform an action, such as solving an application-layer graphic Turing test (GTT).

These approaches can be used within the commonly used perimeter defense paradigm as part of the perimeter defense. However, within an SOA, an approach to defend against Distributed Denial of Service attacks is needed at every service gateway device or service in case the perimeter defense is penetrated or the attack is from an insider. An SOA approach using a security infrastructure composed of interoperable security services and devices, including routers and firewalls, could allow this approach to be done at the enterprise level. The advantage to this would mean, if an attacker failed in a Denial of Service attack against one enterprise IT asset, and switched the attack to another asset, the attack against the new asset would be already mitigated.

As traffic levels increase, clients are required to solve more and more difficult puzzles in order to obtain connections, allowing the server to require the clients to consume resources at a great enough level to prevent them from overwhelming the target system.

While Client Puzzles are viewed as a promising technique to prevent Denial of Service attacks that are aimed at consuming resources, the approach must be enhanced to be effective against Denial of Service attacks that employ a flood of messages to make network bandwidth unusable by legitimate users. Mahimkar et. al. present an approach that moves the generation of client puzzles to a distributed puzzle distribution layer. Their approach also uses distributed monitoring to have an enterprise view of the traffic statistics and distributed filtering to filter traffic based on client solutions to the puzzles. It would be natural in an SOA to implement all of these components of the Denial of Service prevention as services themselves managed from a central security administration point.

In an SOA context, service monitoring would allow corrective action if this balance were to become upset. For example, if an attacker launched an attack that depended on the capability of defeating the GTTs being sent the by target system back to the clients, the target system could dynamically start deploying GTTs of a more difficult class that were reserved in advance. The same approach could be used for client puzzles that consume client system resources. An attacker might defeat the existing set of client puzzles by caching the answers or exploiting a weakness. This could be detected by noticing the client returning the correct answer quicker than expected. The gateway security service could dynamically deploy a more difficult class of client puzzles, or begin deploying GTT client puzzles in order to defeat the attack. Afandi et. al. present a policy-based architecture that could be used for dynamic deployment of Client Puzzles and GTTs. Wohlsteder et. al. present an example of a security policy allowing a client to express preferences for using Client Puzzles, authentication, or both in order to access a service.

In the process of analyzing the how the current state of the art in Denial of Service prevention can be applied in an SOA context, an interesting pattern can be seen to be emerging. At the same time that security policies and enforcement is being abstracted away from the applications, the network infrastructure is getting more sophisticated and one can see a merging of intelligent network components and security services into an integrated set of security services in an SOA. The value of an SOA approach in dealing with one of the most difficult security challenges faced today is also becoming clear.

SOA Security Overview

2006-12-01T09:52:00.001-08:00

Elements of SOA Security

• Three main areas of concern have been recognized to be part of the SOA security arena:
• Message Level Security provides the ability to ensure security requirements are met within an SOA environment, where transport level security is inadequate because transactions are no longer point-to-point in SOA
• Security as a Service provides the ability to implement security requirements for services by using security services including Policy Decision Points and Policy Implementation Points
• Declarative and Policy-Based Security provides the ability to implement security requirements that are transparent to the security administrators and that can be used to quickly implement emerging new security requirements or security services for services that are being created to rapidly implement new business functionality

Message Level Security
• The OASIS set of WS-Security standards have been created to address message level security and are supported by key vendors including IBM, Microsoft and Oracle
• The set of standards are intended to provide the following:
– a secure conversation model describing how to manage and authenticate message exchanges between parties including security context exchange and establishing and deriving session keys
– a Web service endpoint policy describing the capabilities and constraints of the security and other business policies on intermediaries and endpoints including required security tokens, supported encryption algorithms and privacy rules
– a federated trust model describing how to manage and broker the trust relationships in a heterogeneous federated environment including support for federated identities
– a Web service trust model describing a framework for trust models that enables Web services to securely interoperate
– an authorization model describing how to manage authorization data and authorization policies
– a Web service privacy model describing how to enable Web services and requesters to state subject privacy preferences and organizational privacy practice statements

Security as a Service
• Security as a Service can be accomplished by the following:
• Collecting an inventory of service security requirements throughout the Enterprise Architecture
• Specifying the set of discrete security services that will be needed for the enterprise
• Designing and implementing these security services as services themselves within the Enterprise
• A toolkit approach would specify the set of typical security services that could provide most of the requirements and provide a springboard to establish the Security as a Service model in an organization

Declarative and Policy-Based Security
• The implementation of Declarative and Policy-Based security requires tools and techniques for use at the enterprise management level and at the service level
• These tools and techniques should provide:
– Transparency for security administrators
– Policy enforcement
– Policy monitoring
– Policy violation alerts
– Data traceability
– User traceability
• This work can leverage previous initiatives in Quality of Service (QuOS) and Policy-Based Networking

Foundations of SOA Security
• The foundations of SOA security are already widely used in the IT industry, but must be understood by SOA practitioners in order to provide adequate security for the systems being developed
• These building blocks are:
– Public Key Infrastructure
– Kerberos
– XML Encryption
– XML Digital Signatures

SOA Security Roadmap
• A roadmap for SOA security, covering the three areas of Message Level Security, Security as a Service and Declarative and Policy-Based Security would be useful for SOA practitioners
• Microsoft and IBM jointly created an initial roadmap when they were working to create the WS-Security set of standards
• This roadmap can be expanded to cover the areas that emerged later including Security as a Service and Declarative and Policy-Based security, re-targeted for practitioners rather than standards committee members

SOA Security Design Patterns
• Design Patterns were introduced in 1994 as a way to represent best practices for the design of Object-Oriented software and are widely used in the industry
• Microsoft and IBM have been starting to develop a set of design patterns for SOA, mostly focusing on message level security
• Design patterns are needed for the provision of each of the standard security requirements at the enterprise level, in order to provide basic services, monitoring and alerts, using the Security as a Service model of SOA
• Enterprise level design patterns are needed for the implementation of Declarative and Policy-Based Security at the enterprise management level and at the security service level

SOA Security in the Enterprise
• A number of paradigm shifts in the IT industry are happening in the same time frame as SOA adoption
• Organizations are establishing Enterprise Architectures and using them as the basis for IT governance
• Organizations are leveraging the Grid model of computation in order to reduce costs and improve availability
• Organizations are adopting wireless, mobile, and RFID technologies that are recognized to be part of the emerging Pervasive Computing paradigm
• All of these parallel technology initiatives need to be taken into account when considering SOA security

Problems for SOA Security in the Federal Enterprise
• Enterprise Architecture inventories are being undertaken by agencies as the first step toward adopting Enterprise Architectures that fit within the overall Federal Enterprise Architecture
• E-Government initiatives including E-Authentication, HSPD-12, Business Gateway, PAY.GOV and others are impacting agencies
• Agencies are working with wireless, mobile, and RFID technologies that are recognized to be part of the emerging Pervasive Computing paradigm (also referred to as Ubiquitous Computing or Everyware)
• There has so far been limited awareness of the Grid model within the DOT and perhaps other agencies
• All of these must be taken into account when considering SOA security for Federal enterprises

Tools for SOA Security in the Federal Enterprise
• A roadmap for implementing SOA security within the wider context of establishing and following an Enterprise Architecture would provide value for SOA practitioners
• Documentation is needed for bridging the gap between the NIST standards documentation and IT system design and development for HSPD-12 would provide value for SOA practitioners within the Federal sector
• A survey of the security work being done within the Pervasive Computing field would be helpful for SOA practitioners who are faced with the convergence of wireless, mobile and RFID technologies with SOA in their current project
• An assessment of the security concerns in implementing SOA along with the Grid model would help SOA practitioners who are working with the Grid model

Research Areas Related to SOA Security
• The convergence of Virtualization, Grid and SOA is a key research area for Intel’s Software Solutions Group
• One of the most comprehensive approaches of enterprise security being taken is the Trusted Virtual Domain initiative being undertaken between the T.J. Watson, IBM Zurich and IBM Tokyo Research Centers
• A survey of the findings of these groups and others would be useful for SOA practitioners faced with the challenges of implementing systems for complex enterprises such as Federal agencies that interact with many other organizations in a set of overlapping virtual enterprises