# Presentation: 301136

## January 19, 2005

- Andrew Nash
- Chief Technology Officer, Reactivity

**xmlCoP**
**Interoperable Trust Networks**

## Web Service Aggregator ExampleBrowser Redirection

**Web Service Aggregator Example****Browser Redirection**

- Yahoo shopping portal searches for products and lowest prices across all storefronts
- Search results displayed at Yahoo
- Users redirected to backend web sites belonging to vendors
- Interactions with vendors use browser redirects
- Single Sign On achieved using SAML assertions

**HTTP****Redirection**

## Web Service Aggregator Example

**Web Service Aggregator Example**

- Yahoo shopping portal searches for products and lowest prices across all storefronts
- Results aggregated at Yahoo instead of redirecting users to backend web sites
- Common shopping, payment, shipping and query interfaces provided through Yahoo portal
- Interactions with vendors use Web Service transactions
- Complimentary to classic Liberty Federation using browser redirection – avoids changing look and feel

**HTML**

**Web****Services**

## User and Transactional Security

**User and Transactional Security**

**User Security**

**Transactional Security**

- Business transaction model based on XML and Web Services
- Applications exchange transactions – users are not directly involved
- Sender may not originate transactions; does not know the final destination
- Security requirements are based on the content of transaction – not the identity of the applications

**Web****Servers**

**Notes:**
User security associates identity and access management with the actual user.
Transactional security:
May not know who or what originated the transaction
The context of the transaction triggers security actions and business processes
Security roles, policy, and rights are associated with the transaction and not the Web Services
Usually requires searchable logs of activity
Users have identities...transactions carry identifiers

RSA manages security infrastructure
ClearTrust integrates security into user domains
Emerging opportunity is to integrate security infrastructure with the business transaction domain
IBM is directly providing support for both domains
Competitors like Entrust are providing platform level security
Startups are moving aggressively into this space

## Overlapping Web Security Standards

**SAML**

**User Federation**

**Web Services**

**Liberty ID FF**

**WS-Federation WS-Federation**

**WSS**

**WS-Trust**

**WS-Secure****Conversation**

**SOAP**

**HTTP**

## Security Assertions Markup Language

- Framework for exchanging security assertions
- Profiles will map assertion use to messaging frameworks
- Use Cases
- Single Sign-On
- Web user authenticates at a Web site. Web user then accesses another Web site without re-authenticating
- Authorization Service
- User attempts to access a resource or service. The access controller for that resource (policy enforcement point) checks the user's rights with a policy decision point
- Attribute Service
- User moves from one web site to another – customer loyalty information or context is passed to simplify  the users experience as part of a federated information services

## SAML Domain Model

## SAML Assertion Request Protocol

## Where Does Liberty Fit?

- Liberty Alliance is focused on SSO and user information sharing using a federated identity model
- Liberty is an application domain standard
- Builds on standards defined elsewhere to solve the application domain problems
- Liberty will uses SAML V2 for infrastructure support
- Liberty move to WSS

**SOAP**

**WS Security**

**SAML**

**Other Federation **
**Enabling Standards**

**Liberty Alliance**

## Liberty & SAML

**Attribute Assertion**

**Authentication Assertion**

**SAML**

**Authentication****Authority**

**Attribute****Authority**

***Liberty Identity Provider***

***Liberty Service Provider***

**Authorization Decision Assertion**

**SAML**

**SOAP Foundation**

## Liberty Identity Federation

**PartnerA.com**

**“****Circle of Trust”**

**BusUnit1.com **

**MyCompany.com**
**(ID Provider)**** **

_**Federated ID**_
**SecurityDomain=“BusUnit1.com" **
**    ****Name=“Jack"**
**SecurityDomain=“PartnerA.com"**
**    ****Name=“John"**

_**Federated ID**_
**SecurityDomain=“BusUnit1.com" **
**    ****Name="dTvIiRcMlpCqV6xX" **
**SecurityDomain=“PartnerA.com"**
**    ****Name="pfk9uzUN9JcWmk4RF"**

## Liberty/SAML Web SSO Model

**Identity**
**Provider**

**“****Circle of Trust”**

**Service**
**Provider**

**Authentication Authority**
- Attribute Authority

## IBM/Microsoft Web Services Architecture

**SOAP Foundation**

**WS-Security**

**WS-Policy**

**WS-Trust**

**WS-Privacy**

**WS-Secure ****Conversation**

**WS-****Federation**

**WS-****Authorization**

**Standards****Body**

**Published****Specs**

**Unpublished****Specs**

## What’s in a Name?

- WS-Security(aka WSS)
- WS-Trust
- WS-Policy
- WS-SecurityPolicy

- SOAP Message Security only, does not cover other aspects of security for web services
- Issuance and exchange of security tokens – not establishment and validation of trust
- Policy definition framework, does not describe how policies are managed
- How security information is passed, not how security policy is distributed or enforced

## WS-Security

- Describes how to secure SOAP messages
- Defines how to identify the creator of the message
- Carries multiple credential types including
- Message Integrity
- Integrity of all or part of a message
- Builds on XML-Signature
- Supports multiple and overlapping signatures
- Message Confidentiality
- Confidentiality of all or part of a message
- Builds on XML-Encrypt

## Securing SOAP Messages

- WSS information stored in SOAP security header
- One or more security tokens carried in header to identify the transaction
- XML Signature blocks may be carried to provide integrity and link the identity to the transaction
- Key information within the security token may be used
- Privacy provided using XML encryption

**wsse:**

**security token**

**signature **

**key info**

## Security Tokens

- Separate profiles define the format and usage rules of various token types
- Username/password
- Binary Security Tokens
- Encoding type like Base-64 allows inclusion in XRML
- X.509
- Kerberos
- XML Tokens
- SAML
- XRML
- Common Biometric Format
- Great ... but where do we get these security tokens from...?

## WS-Trust

- A Security Token Service (STS) issues tokens that can be used in WSS
- Forms the basis for several other WS-* standards (coming up)
- Token issuance, renewal and validation are handled by an STS
- The services of an STS may be required by web services and their clients
- Security tokens are a collection of claims about a resource
- The claims presented in security token are examined in the light of the policy controlling the web service

## Web Services Trust Model

**Security****Token****Service**

**Policy**

**Security****Token**

**Claims**

**Web****Service**

**Policy**

**Security****Token**

**Claims**

**Requestor**

**Policy**

**Security****Token**

**Claims**

## WS-Policy

- Framework for defining policies parameters or assertions that affect web services
- WS-PolicyAttachment describes how policies are associated with a resource
- WS-PolicyAssertions defines a common set of assertions
- Establishes a mechanism for exchanging requirements between a web services provider and client
- Provides machine readable policy statements that describe the operational parameters for interactions between a service and a client
- Supports negotiation of the parameters defined within a policy

## WS-Policy

- Policy is defined as a series of assertions
- Each has a usage (required, optional, rejected etc) and preference (ranking of this assertion)
- Operators (all, exactlyone, oneormore) define how to evaluate child assertions
- WS-PolicyAssertions define common assertion types
- (TextEncoding, Language, SpecVersion)
- WS-PolicyAttachment supports
- a standalone option that allows a standalone description of the web service that the policy is associated with
- Or integrated with WSDL where a series of pointers reference a policy

## WS-SecurityPolicy

- Defines assertions that address security parameters
- SecurityToken identifies
- Types of security tokens accepted
- Issuer of the token
- Optional details about particular token types (e.g. what set of user names are supported)
- Integrity
- What parts of a message are signed
- XML signature algorithms used
- Parameters defining how the algorithm should be executed

## WS-SecurityPolicy

- Confidentiality
- What parts of a message are encrypted
- Algorithms and parameters used
- Visibility
- What parts of a message must be visible to intermediary web services
- SecurityHeader
- Constrains how the security header is processed
- MessageAge
- Acceptable message lifetime based on the WSS timestamp

## WS-SecureConversation

- Eliminates the overhead of carrying and validating authentication information in each message
- Establishes a mutually authenticated security context
- Multiple messages may be exchanged within this context
- Creates an end-to-end secured channel at the application layer
- Like SSL it is provides a session oriented authenticated and encrypted data pipe
- SSL is restricted to point-to-point sessions between intermediate nodes

## WS-Federation	

- Describes how to share identities and attributes across multiple trust domains
- Layered on WS-Trust
- Tokens issued by one domains STS are used to request a new security token from the STS of another domain

## Federation Token Exchanges

**Security****Token****Service**

**Policy**

**Security****Token**

**Web****Service**

**Policy**

**Security****Token**

**Requestor**

**Policy**

**Security****Token**

**Trust Relationship**

**Trust Domain 1**

**Trust Domain 2**

**1**

**2**

**3**

**4**

## WS-Federation Sequence

**Requestor**

**Web Service**

**Requestor****STS**

**Web Service****STS**

**Rqst Security Token**

**Issue Security Token**

**Rqst Security Token with Token Reference**

**Issue Security Token from Service Domain**

**Invoke Service w Security Token**

**Validate Security Token**

**Approve Security Token**

**Return Service Response**

## Security and Privacy - Today

- Today transactions are secured using WSS toolkits to implement the Web Service security standards
- Usually support for X.509 Certificates or password credentials

**HTML**

**SWS + password / X.509 Cert**

## Security and Privacy – “Tomorrow”

- SAML Tokens for use in WSS security headers to support Federated Identities
- User Authentication supplied by CT/FIM
- Requests SAML assertions from SAML authority to build SAML tokens
- Crossover from Browser/User security world to Web Services

**HTML**

**WSS + SAML Token**

**WSS with****SAML **

**SAML Authority**

**Login**

**SAML Assertions **

## Security and Privacy – “Tomorrow”

- Web services infrastructure moves toward WS-Trust credential servers for token issuance and support of WS-Federation
- WS-Trust toolkits provide messaging and protocol support for development of clients and servers

**WSS+Token**

**WS-Trust**

**WS-Trust****Credential Server**

**Tokens **

**WS-Federation Ids**

**WS-Trust Server Tk**

## Web Service security dilemma

**Database****Integration**

**User****Interface**

**Security**
**Layer**

**Business Logic**

- CIO’s and IT Directors do not believe application programmers can verifiably implement enterprise security policies
- Use of toolkits does not scale to even modest deployments
- Tools do not exist to define, verify or modify security policy
- Transactions must be monitored and audited
- Security policy management must be federated

**Notes:**
DSG will provide the security integration components for application-specific Web Services security, but there is a much larger opportunity – Enterprise Security Management.

Web Services is now the dominant application integration approach (The Burton Group, Feb. 12, 2003)
Core standards are stable, vendor support broad, enterprise initial production deployments increasing
High ROI on Web Services from fewer proprietary systems to support and interface with, higher speed data flow between systems and partners, and reusing functionality across applications.
Security models that rely on application programmers do not scale...opening new opportunities for security management
Architecture dictates that every developer to integrate sophisticated security APIs and policy such as WS-ME
Policy must be implemented across all services and platforms with varied/disparate security levels
Integration with future component may break security model and one misstep can expose entire network across business partners
Multiple platforms and versions

## Perimeters?

## Cherry Picking from Different Domains

**Network****Domains**

## Controlling a Service Oriented Application

**Controlling a Service Oriented Application**

## Reactivity in the enterprise

## The Reactivity Gateway Message Pipeline

## The Reactivity Gateway Message Pipeline

## Multi-layer mediation of transactions

- Data transformation
- ex. service virtualization
- Security Credential Mapping
- ex. SSL external to SAML internal
- Transport mapping
- ex. XML/MQ to SOAP/HTTPS
- Cross-layer information sharing with advanced header manipulation

## Reactivity’s Policy Aware Core

**Report & Audit**

- Optional sub-polices allow secure separation between projects, business units, geographies

**Deploy Policy and Mark Messages**

**Collaborate & **
**Compare Policy**

**Delegate & **
**Create Policy**

**Control**

**Agility**

- Visually identify policy conflicts
- Multi-stage approval for efficient workflow

- Policy version linked to message pair ensuring consistency and auditability
- One-click deploy & rollback for efficiency

_**Functions**_

_**Benefits**_

- Policy aware event and message logs enable rapid issue identification and accurate audits

***Policy Aware Core ensures XML Web services security with speed, flexibility and visibility***

## Reactivity’s Vision of XML Infrastructure

_**Application Infrastructure**_
**Server/Application  Based Functions**

_**Network Infrastructure**_
**Packet based functions **

_**XML Infrastructure**_
**XML Message based functions** –
- A new layer required for connecting distributed
- XML web services and enforcing message transport policies

**Notes:**
Only give this and the next slide to prospects who haven’t narrowed their field to just Web services gateways.  And if you aren’t in a slide friendly meeting, you should be able to white board this.