SCT Security - Demo - Sprint 1

Report
Single sign on and
authorization
Unifying security for the sct product set
SDL Proprietary and Confidential
Agenda
•
Introduction
•
Theory
•
•
•
•
2
–
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
Theory
SDL Proprietary and Confidential
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 authorized
to buy beer
4
Terminology
• 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)
5
Terminology
• 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)
6
Terminology - Claim
• 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
7
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 W S-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?
SCT
Structured Content Technologies
SDL Proprietary and Confidential
Applications
•
•
•
•
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)
–
–
•
13
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.
Topology – Current
Appz
Domains/XSS
DataFlow
(Protocols/arrows)
Firewalls
STS/IdP
GAMS-CT
TS-CT
GAMS-Lib
Thick Client
Browser
XO-Client
Browser
Browser
XO-Client
Web Client
TS-Web
XO-Web
LC-Web
GAMS-Profile
Trusted subsystem
Arrows with
preconfigured
or hardcoded
authentication
XO-Web
Web Sites
TS-WS
Services
XPP
WS
App/Data layer
TMS-CC
TS-CMS
TMS
Trados
MT
SDLX
Topology - Desired
STS
GAMS-CT
TS-CT
LC-.NET-Client
Thick Client
Browser
Browser
XO-JS-Client
Browser
Browser
GAMS-Web
Dash-Web
LC-JS-Client
GAMS-JS-Client
LC-JS-Client
Web Client
TS-Web
LC-Web
XO-Web
Arrows with
Identity
Delegation
Web Sites
TS-WS
GAMS-WCF
Services
XPP
WS
App/Data layer
TMS-CC
TS-CMS
TMS
Trados
MT
SDLX
IDP
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?
Prototype
SDL Proprietary and Confidential
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
– [email protected] located in Mechelen hosting Agency and
BookingService
– [email protected] located in Wakefield hosting Airline
– [email protected] 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)
Topology
Rich Client
Browser
Agent
Browser (Agency)
Browser
Web
Browser (Airline)
Client
Agency
STS
Web
Svc
Web App
Booking
Service
Services
E-Mail
Service
Background Services
Not Yet Implemented
Airline
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
Browser (Agency)
Agency
Agent
Booking
Service
Web
Svc
Airline
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.
Browser
Agency
Agent
Web
Booking
Service
Web
Svc
Airline
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)
Web
Svc
Airline
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.
E-Mail
Service
Booking
Service
Web
Svc
Airline
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)
Agency
Booking
Service
Claim Types
• Common
– 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)
Claims Transformations on STS
– e-Mail (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress)
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?
Experience
SDL Proprietary and Confidential
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
Future
SDL Proprietary and Confidential
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.

similar documents