SDL Proprietary and ConfidentialSDL Proprietary and Confidential

Single sign on and authorization

Unifying security for the sct product set

• Introduction

• Theory

– Real life example

– Terminology

– Profiles

– Standards

• SCT

– Applications

– Network Topology

– The why slide

– Proof of Concepts

• Prototype

– Introduction

– User Stories

– Proof of Concepts

• Experience

– ADFS

– Apache STS (NotTested)

– .NET Possitives and Negatives

– JAVA Possitives and Negatives

• Future

– Remaining Work

– Impact for existing products

– Team Members

Agenda

2

SDL Proprietary and ConfidentialSDL Proprietary and Confidential

Theory

4

Real Life Example

1. You need resources, so off to the supermarket to buy some good beer, e.g.

2. The policy of the supermarket is not to sell to minors, hence the photo id required

3. Your token is

4. Your token was issued before by the state, a trusted identity provider

5. After verification of your age claim, part of your token, you are authorizedto buy beer

5

• Identity: security principal used to configure security policy (Person)

• Identity Provider (IdP): producer of assertions (Government)

• Security Token: a set of claims digitally signed by issuing authority (for example, Windows security tokens or SAML tokens) (Identity Card)

• Security Token Service (STS) / Issuing Authority: the authentication provider, builds, signs and issues security tokens (for example, ADFS, PingFederate) (Town hall, DMV)

• Claim: assertion / attribute of an identity (Login name, AD Group, etc.) (Age)

• Relying Party (RP): application that makes authorization decisions based on claims (Liquor Store)

• Service Provider (SP): consumer of assertions(Liquor Store)

Terminology

6

• Authentication is the process of verifying a claim made by a subject that it should be allowed to act on behalf of a given principal (person, computer, process, etc.). (Check Identity Card)

• Authorization involves verifying that an authenticated subject has permission to perform certain operations or access specific resources. (Check Age)

• Single Sign-On (SSO) is a property of access control of multiple, related, but independent software systems. With this property a user logs in once and gains access to all systems without being prompted to log in again at each of them. (Use same Identity Card everywhere)

• Federation describes a scenarios in which no one group or organization manages all users and resources in a distributed application environment. Instead, administrators in diverse domains must manage local security policies. (Passport and Identity Papers across different countries)

Terminology

7

• Claim

– ClaimType

– Issuer

– Value

– Value Type

• Example of Claims of Claim Types

– First name

– Gender

– Age or IsAdult

– City

• Example of Claim Set / Security Token

– First name = Alex

– Gender = Male

– Age = 33 or IsAdult = true

– City = Mechelen

Terminology - Claim

Profile – Active

1. The relying party exposes policy that describes its addresses, bindings, and contracts (using WS-Policy). But the policy also includes a list of claims that the relying party needs, for example user name, email address, and role memberships. The policy also tells the smart client the address of the STS (another Web service in the system) where it should retrieve these claims.

2. After retrieving this policy (1), the client now knows where to go to authenticate: the STS. The smart client makes a Web service request (2) to the STS, requesting the claims that the relying party asked for through its policy. The job of the STS is to authenticate the user and return a security token that gives the relying party all of the claims it needs.

3. The smart client then makes its request to the relying party (3), sending the security token along in the security SOAP header.

Smart clients are referred to as “active” because they have plumbing (WCF, for example) that can parse policy and implement WS-Trust directly. Web browsers are referred to as “passive” because they can’t typically be modified to do these things directly, so cookies, redirection, and JavaScript are used mimic the WS-Trust protocol in a browser-friendly way.

Profile – Passive

1. The user points her browser at a claims-aware Web application (relying party). WS-Federation

2. The Web application redirects the browser to the STS so the user can be authenticated. The STS is wrapped by a simple Web application that reads the incoming request, authenticates the user via standard HTTP mechanisms, and then creates a SAML token and emits a bit of JavaScript.

3. This JavaScript causes the browser to initiate an HTTP POST that sends the SAML token back to the relying party.

Standards - Overview

• Many standards each compiled out of different tokens, protocols and bindings; backed by organizations.

Liberty Alliance Project contributed their ID-FF 1.2 into SAML 2.0

OASIS SAML 2.0; successor of 1.1, includes Liberty and Shibboleth 1.2 contributions

Internet2 networking consortium Shibboleth 1.2 was merged; their 2.0 is derived from SAML 2.0

WS-Federation backed by Microsoft and IBM, the 1.2 version became an OASIS standard

Questions?

SDL Proprietary and ConfidentialSDL Proprietary and Confidential

SCT

Structured Content Technologies

13

• Live Content (LC)

– Web application for dynamic content publishing

– Can Search inside the structure of the content

– Support DITA1.2 standard

• Trisoft (TS)

– Dita repository

– Publisher

– Client Tools for Editing and Management. (In process)

– Web Tools for …(Browser)

• XOPUS (XS)

– XML Editor (Browser)

– Content Source from Trisoft and Live Content

• Global Authoring Management System (GAMS)

– Client component Integrates with Authoring Environments to check

• Grammar

• Style

• Translation memory

• Terminology

– Server Component acts as Shared Profile Repository

• XPP

– Automated XML publishing engine

– Publish technical documentation for financial, government, high tech, aerospace and defense industries.

Applications

XO-Client

XO-Web

Topology – Current

TS-CT

XO-Web

TS-WS

TS-Web

GAMS-CT

LC-Web

XPP

GAMS-Lib

WS

TMS

Trados

MT

SDLX

AppzDomains/XSSDataFlow (Protocols/arrows)FirewallsSTS/IdP

Browser

GAMS-Profile

XO-Client

Browser

Browser

Thick Client

Web Client

Web Sites

Services

App/Data layer TMS-CCTS-

CMS

Arrows with preconfigured or hardcoded authentication

Tru

sted

sub

syst

em

Arrows with Identity

Delegation

LC-JS-Client

LC-.NET-Client

LC-JS-ClientGAMS-JS-

Client

XO-Web

Topology - Desired

TS-CT

TS-WS

TS-Web

GAMS-CT

LC-Web

XPP

GAMS-WCF

WS

TMS

Trados

MT

SDLX

Browser

GAMS-Web

XO-JS-Client

Browser

Browser

Thick Client

Web Client

Web Sites

Services

App/Data layer TMS-CCTS-

CMS

Dash-Web

Browser

IDP

STS

The why Slide!!

• Unify Authentication across SCT products

– Provide Single Sign On experience to users

– Leverage any Identity Provider a customer has.

• Stop being a trusted subsystem

– Stop using preconfigured or hardcoded authentication on arrows

– Provide more security on the platform

• Stop being responsible for every kind of Identity Provider

– Not responsible for security information

– Not responsible for customer individual policies e.g. Password policy

• Adopt Industry Standards for protocols and tokens

– Open suite for future trust with other products

• Provide infrastructure for new applications in the Suite (Dashboard)

• Future compatibility.

– Everything points to this direction.

– Cloud compatibility

Proof of Concepts

• Passive Profile

– Browser Logon

– Cross domain Display of Content and transparent Java Script execution

• Active Profile

– In process application makes requests to web service

• Identity Delegation

– Application makes requests to other application

– Background task executes on behalf of user

Questions?

SDL Proprietary and ConfidentialSDL Proprietary and Confidential

Prototype

Introduction - Story

• Travel Agency

– Profiled Based Vacation Browsing

– Book Vacation

– Display Booking Details

– Custom Users

• Airline

– Electronic Check In

– Display Flight Status

– Custom Users

Introduction - Enhancements

• Authentication

– Single Sign On

• Travel Agency

– Books also Flight when booking Vacation

– Shows also Flight Status with Book Details

– Shows also if Electronic Check in has been made with Book Details

– Send Emails based on Booking Details.

• Airline

– Informs Travel Agency when customer made electronic Check In

– Provides live information about Flight Status

Introduction – Domains

• Travel Agency .NET (Red) (Trisoft)

– Agency: MVC Web Application

– BookingService: WCF Web Services

– Agent: Desktop Application

– EmailService: Console Application

• Airline JAVA (Green) (Live Content)

– Web Application

– SVC Restful API

• Identity Providers

– Active Directory

– Open LDAP

• STS

– ADFS 2.0

– Ping Federate

Prototype Relation with SCT Suite

User Stories

• Profile Based Vacation Browsing

• Book Vacation

• Display Booking Details

• E-CheckIn

• Email (Not yet implemented)

• Display Claims

Demo

• Servers

– MECDEVAPP02@Global located in Mechelen hosting Agency and BookingService

– WKENSV0306@Global located in Wakefield hosting Airline

– strts01@ams.dev located in Amsterdam hosting ADFS

• DEMO

– Agency (https://mecdevapp02.global.sdl.corp/Agency/)

– eCheckin (https://wkensv0306.global.sdl.corp:8443/Airline/code/Welcome.jsp)

– Agent (\\mecdevapp02\C$\WebSites\TravelAgency\Agent\Desktop.exe)

BrowserRich Client

Topology

Client

Agent Browser (Agency) Browser (Airline)

Web App

Agency

Services

AirlineWeb

Svc

Booking Service

Background Services

E-Mail Service

Browser Web

STS

Not Yet Implemented

User Story – Profile Based Vacation Browsing

• Browser

1. User enters the Agency application through his web browser.

2. If the user is not authenticated, the user is redirected to the proper STS and after a successful sign on he is returned to the travel agency's application

3. The user navigates among available vacations that are optimized for his profile. "Browse" page

• Application

1. User starts the Agent from his desktop.

2. User enters credentials and the application silently authenticates him on the STS

3. The user makes "Browse" request to Agency and navigates among available vacations that are optimized for his profile. (Not yet implemented)

Agent Browser (Agency)

Agency

User Story – Book Vacation

• Browser

1. Signed on user books a vacation from browser.

2. Agency Web Application sends "Book" request to Booking Service with identity delegation

3. Booking Service executed internal business flow (Issue of persisting user's token))

4. Booking Service send "Book" request to Airline Rest Service with identity delegation

• Book (Application)

1. Signed on user books a vacation from Agent.

2. Application sends "Book" request to Booking Service with user's token

3. Booking Service executed internal business flow (Issue of persisting user's token))

4. Booking Service send "Book" request to Airline Rest Service with identity delegation

Agent

Browser (Agency) Agency

AirlineWeb

Svc

Booking Service

User Story – Display Booking Details

• Browser

1. Signed on user requests details for his travel plans from browser

2. Browser enters "BookingDetails" Page

3. Browser requests data from Agency which makes "Detail" request to Booking Service with identity delegation

4. Browser makes "FlightStatus" request data to Airline Rest Service using Single Sign On. (Not yet implemented)

• Application

1. Signed on user requests details for his travel plans from Agent

2. Application makes "Detail" request to Booking Service

3. Application creates requests token for Airline Rest Service from STS

4. Application makes "FlightStatus" request to Airline Rest Service passing proper token.

Agent

Agency AirlineWeb

Svc

Booking Service

Browser Web

User Story – eCheckIn

• Browser (Web Brower SSO Profile - SP initiated: Redirect -> POST binding)

1. User tries to access Airline's application resources through web browser.

2. If the user is not authenticated, he is redirected to the STS and challenged for credentials. After user enter his credentials, STS sends browser SAMLResponse token. Browser send SAMLRespone token to Airline application through HTTP POST.

3. Airline application validate token and allow user access e-checkin service.

4. Airline Web Application executes request and handles internal business flow

5. Airline Web Application makes "CheckIn" request to Booking Service with identity delegation. (Not yet implemented)

Browser (Airline) AirlineWeb

Svc

Booking Service

User Story – Email (Not yet implemented)

• Periodic Event

1. Service gets activated

2. Service polls for pending emails. 

3. If no pending e-mails are found, service is deactivated for specific period

4. Service acquires (persist strategy needs to be defined) related user's authorization token

5. Service executes "Detail" request to Booking Service using this token

6. Service executes "FlightStatus" request to Airline Rest Service using this token

7. Service sends e-mail.

AirlineWeb

Svc

Booking Service

E-Mail Service

User Story – Display Claims

• Browser

1. Signed on user clicks Claims from browser.

2. Agency calculates claim set for Agency Domain

3. Agency Web Application sends "TransformClaimsPrincipalToModel" request to Booking Service with identity delegation

4. Booking Service calculates claim set and returns data

5. User sees report for the two claim sets.

Browser (Agency) AgencyBooking Service

Claim Types

• Common

– e-Mail (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress)

– Username

• Travel Agency

– Username (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn)

– DisplayName (http://TravelAgency/identity/claims/DisplayName)

– Country (http://TravelAgency/identity/claims/Country) (Transformation on Service Provider using Group claim type)

• Airline

– Username (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier)

– Title (http://schemas.microsoft.com/ws/2008/06/identity/claims/role)

– Department (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/department)

Cla

ims

Tra

nsfo

rmat

ions

on

ST

S

Proof of Concepts

• Passive Profile

– Browser Logon (Profile Based Vacation Browsing, eCheckIn)

– Cross domain Display of Content and transparent Java Script execution(Display Booking Details with FlightStatus). (Not yet implemented)

• Active Profile

– In process application makes requests to web service (Profile Based Vacation Browsing)

• Identity Delegation

– .NET Application makes requests to .NET application (Book Vacation, Booking Details, Claims).

– .NET Application makes requests to JAVA application (Book Vacation).

– JAVA Application makes requests to .NET WCF Service (e-CheckIn) (Not yet implemented)

– Background task executes on behalf of user (Email Service). (Not yet implemented)

Questions?

SDL Proprietary and ConfidentialSDL Proprietary and Confidential

Experience

ADFS

• Positives

– Free

– UI Configuration of Relying Parties

– Support for WS-Federation and SAML1.1 and SAML2 tokens

– Powered by .NET Windows Service and .NET Web Application

– Based on WIF

– Can interact with other federation services as federation partners that are WS-* and SAML 2.0 compliant

• Negatives

– Difficult Syntax for custom claims transformation rules

– Only Active Directory Domain Services can be used as an identity provider

• Still Unknowns

– No hands on experience with scaling out.

.NET Possitives and Negatives

• Positives

– Windows Identity Foundation (WIF)

– Windows Communication Foundation (WCF)

– Federation Utility from WIF SDK really helps with development and deployment.

– Possible Compatibility with Windows Workflow (WF)

– Active Profile completely transparent. No dependency on WIF

– Easily Implement Identity Delegation between .NET domains.

• Negatives

– Mainly SAML1 and WS-Federation

– WIF is lacking complete support of SAML2. Nothing official about new release.

– Active Profile is mainly based on WS-Federation protocols.

– Difficult to deploy because of certificate dependency.

.JAVA Possitives and Negatives

• Positives

– OpenSAML APIs available to build SAML token consumer

– Flexible to work with different STSs

• Negatives

– Takes time to build – No suitable frame work

– No clear industry directions available - Need lots of research and test

Summary

• Positives

– Overcome The Double-Hop Problem with Identity Delegation

• Applications do not use Windows Principal through the execution context

• Instead a claim set is available that describes user’s potential

• Specify/Limit actors for identity delegation

– Authentication agnostic.

• No need to care for Authentication

• No Need to maintain Identity Providers. Not responsible for persisting security sensitive information. Not responsible for enforcing different password policies.

• Just get claims through a token.

– Token Encryption through certificates.

– Flexibility in Authorization.

– Customization with Claim Rules Transformations

– Future trust and extension with third party applications

• Negatives

– Steep learning curve

– Required some theory and experience with certificates

– Required more theory and experience with security.

– Special care for User Provisioning needed. Define best scenario that minimize how stale is data and how to securely persist tokens.

– Required certificate provisioning

SDL Proprietary and ConfidentialSDL Proprietary and Confidential

Future

Remaining Work

• Passive Profile

– Browser Logon (Profile Based Vacation Browsing, eCheckIn)

– Cross domain Display of Content and transparent Java Script execution(Display Booking Details with FlightStatus). (Not yet implemented)

• Active Profile

– In process application makes requests to web service (Profile Based Vacation Browsing)

• Identity Delegation

– .NET Application makes requests to .NET application (Book Vacation, Booking Details, Claims).

– .NET Application makes requests to JAVA application (Book Vacation).

– JAVA Application makes requests to .NET WCF Service (e-CheckIn) (Not yet implemented)

– Background task executes on behalf of user (Email Service). (Not yet implemented)

Remaining Work

• Finish rest of Proof of Concepts

• STS

– Check with alternative STS (Ping Federate)

• Identity Provider

– Check with Open LDAP

Impact on products

• Trisoft

– Find a solution that works for both technologies for the transition period, without compromising WCF/Claims potential

– Gradually migrate VB6 stack to .NET.

– Keep backwards compatibility.

– Verify that active profile can work with .NET3.5 for the client tools

– Find a solution for user provisioning.

• Live Content

– Separate authentication module and authorization module from existing code

– Implement authentication module using newly developed library

– Implement claim aware REST web service API for Trisoft using Java(Using one end point and handling URL parameter is challenging)

– Implement claim aware Java active call to Trisoft .NET WCF Service

• XOPUS

– Import Cross Site Scripting functionality

• GAMS

– Implement new .NET based Services with Claims Awareness

Team Members

• Andrew Trese

• Dave De Meyer

• Gina Choi

• Natalia Balatskova

• Sangeeta Narayan

• Shawn Linderman

• Martin Gill

• Jeroen Laridon

• Alex Sarafian

Questions?

Copyright © 2008-2012 SDL plc. All rights reserved.. All company names, brand names, trademarks, service marks,

images and logos are the property of their respective owners.

This presentation and its content are SDL confidential unless otherwise specified, and may not be copied, used or

distributed except as authorised by SDL.