1 / 47

Single sign on and authorization

Single sign on and authorization. Unifying security for the sct product set. Agenda. 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

hafwen
Télécharger la présentation

Single sign on and authorization

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Single sign on and authorization Unifying security for the sct product set

  2. Agenda • 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

  3. Theory

  4. Real Life Example • You need resources, so off to the supermarket to buy some good beer, e.g. • The policy of the supermarket is not to sell to minors, hence the photo id required • Your token is • Your token was issued before by the state, a trusted identity provider • After verification of your age claim, part of your token, you are authorizedto buy beer

  5. 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)

  6. 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)

  7. 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

  8. Profile – Active • 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. • 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. • 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.

  9. Profile – Passive • The user points her browser at a claims-aware Web application (relying party). WS-Federation • 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. • This JavaScript causes the browser to initiate an HTTP POST that sends the SAML token back to the relying party.

  10. 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

  11. Questions?

  12. SCT Structured Content Technologies

  13. 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) • 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.

  14. Topology – Current AppzDomains/XSSDataFlow (Protocols/arrows)FirewallsSTS/IdP • GAMS-CT • TS-CT • GAMS-Lib Thick Client Trusted subsystem Browser Browser Browser • XO-Client • XO-Client Web Client Arrows with preconfigured or hardcoded authentication • TS-Web • LC-Web • GAMS-Profile • XO-Web • XO-Web Web Sites • TS-WS Services • SDLX • Trados • MT • XPP • WS • TMS • TMS-CC App/Data layer • TS-CMS

  15. Topology - Desired • GAMS-CT STS • TS-CT • LC-.NET-Client Thick Client Browser Browser Browser Browser • XO-JS-Client • LC-JS-Client • GAMS-JS-Client • LC-JS-Client Web Client • TS-Web • LC-Web • GAMS-Web • Dash-Web Arrows with Identity Delegation • XO-Web Web Sites • TS-WS • GAMS-WCF Services IDP • SDLX • Trados • MT • XPP • WS • TMS • TMS-CC App/Data layer • TS-CMS

  16. 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

  17. 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

  18. Questions?

  19. Prototype

  20. Introduction - Story • Travel Agency • Profiled Based Vacation Browsing • Book Vacation • Display Booking Details • Custom Users • Airline • Electronic Check In • Display Flight Status • Custom Users

  21. 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

  22. 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

  23. Prototype Relation with SCT Suite

  24. User Stories • Profile Based Vacation Browsing • Book Vacation • Display Booking Details • E-CheckIn • Email (Not yet implemented) • Display Claims

  25. Demo • Servers • MECDEVAPP02@Globallocated 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)

  26. Topology RichClient Browser Browser Web Agent Browser (Agency) Browser (Airline) Web App Services Client Agency Web Airline Svc STS Booking Service E-Mail Service Not Yet Implemented Background Services

  27. User Story – Profile Based Vacation Browsing • Browser • User enters the Agencyapplication through his web browser. • 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 • The user navigates among available vacations that are optimized for his profile. "Browse" page • Application • User starts the Agent from his desktop. • User enters credentials and the application silently authenticates him on the STS • 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

  28. User Story – Book Vacation • Browser • Signed on user books a vacation from browser. • Agency Web Application sends "Book" request to Booking Service with identity delegation • Booking Service executed internal business flow (Issue of persisting user's token)) • Booking Service send "Book" request to Airline Rest Service with identity delegation • Book (Application) • Signed on user books a vacation from Agent. • Application sends "Book" request to Booking Service with user's token • Booking Service executed internal business flow (Issue of persisting user's token)) • Booking Service send "Book" request to Airline Rest Service with identity delegation Web Airline Svc Agency Browser (Agency) Booking Service Agent

  29. User Story – Display Booking Details • Browser • Signed on user requests details for his travel plans from browser • Browser enters "BookingDetails" Page • Browser requests data from Agencywhich makes "Detail" request to Booking Service with identity delegation • Browser makes "FlightStatus" request data to Airline Rest Service using Single Sign On.(Not yet implemented) • Application • Signed on user requests details for his travel plans from Agent • Application makes "Detail" request to Booking Service • Application creates requests token for Airline Rest Service from STS • Application makes "FlightStatus" request to Airline Rest Service passing proper token. Browser Web Web Airline Svc Agent Booking Service Agency

  30. User Story – eCheckIn • Browser (Web Brower SSO Profile - SP initiated: Redirect -> POST binding) • User tries to access Airline's application resources through web browser. • 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. • Airline application validate token and allow user access e-checkin service. • Airline Web Application executes request and handles internal business flow • Airline Web Application makes "CheckIn" request to Booking Service with identity delegation.(Not yet implemented) Web Airline Svc Booking Service Browser (Airline)

  31. User Story – Email (Not yet implemented) • Periodic Event • Service gets activated • Service polls for pending emails.  • If no pending e-mails are found, service is deactivated for specific period • Service acquires (persist strategy needs to be defined) related user's authorization token • Service executes "Detail" request to Booking Service using this token • Service executes "FlightStatus" request to Airline Rest Service using this token • Service sends e-mail. Web Airline Svc E-Mail Service Booking Service

  32. User Story – Display Claims • Browser • Signed on user clicks Claims from browser. • Agency calculates claim set for Agency Domain • Agency Web Application sends "TransformClaimsPrincipalToModel" request to Booking Service with identity delegation • Booking Service calculates claim set and returns data • User sees report for the two claim sets. Booking Service Agency Browser (Agency)

  33. 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) Claims Transformations on STS

  34. 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 withFlightStatus). (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)

  35. Questions?

  36. Experience

  37. 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.

  38. .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.

  39. .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

  40. 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

  41. Future

  42. Remaining Work • Passive Profile • Browser Logon (Profile Based Vacation Browsing, eCheckIn) • Cross domain Display of Content and transparent Java Script execution(Display Booking Details withFlightStatus). (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)

  43. Remaining Work • Finish rest of Proof of Concepts • STS • Check with alternative STS (Ping Federate) • Identity Provider • Check with Open LDAP

  44. 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

  45. Team Members • Andrew Trese • Dave De Meyer • Gina Choi • Natalia Balatskova • Sangeeta Narayan • Shawn Linderman • Martin Gill • Jeroen Laridon • Alex Sarafian

  46. Questions?

More Related