OIOSAML Rich Client to Browser Scenario Version 1.0

Transcription

1 > OIOSAML Rich Client to Browser Scenario Version 1.0 Danish Agency for Digitization December 2011

2 Contents > 1 Introduction Purpose 1.2 Background Goals and Assumptions 5 3 Scenario Details Unsolicited Response Messages Selecting Protocol Binding 7 4 Appendix A: References 9

3 Document History Version Date Initials Changes TG Initial version ready for publication after internal review.

4 1 Introduction > 1.1 Purpose This document describes how a rich client application can bootstrap an authenticated browser session with a web application using [OIOSAML]. The document is purely informational and serves as an illustration of a new scenario that is not included in [OIOSAML]. 1.2 Background In some environments end-users interact with rich client applications (i.e. desktop applications) that need to perform a smooth transition to a web application. As a specific example, consider the health care sector where a doctor could be interacting with an electronic patient journal application at a hospital (a rich client / desktop application). At some point, the doctor may wish to see the result of a laboratory test, which could be a web application to be accessed via a browser (possibly offered by another organization). Here the rich client could use the pattern described in this document to launch a browser that establishes an authenticated session with the laboratory system without requiring the doctor to log-in again. The doctor will hence experience single sign-on from his rich client to the web application. Figure 1: Rich client to browser transition We show below how such a scenario can be realized using [OIOSAML] as the main building block. The reader is assumed to be familiar with OIOSAML and SAML in general. 4

5 2 Goals and Assumptions > The goal is to document a scenario where: A rich client launches a browser with a web application that requires user authentication. The user is not required to log-in to the web application but gets an authenticated browser session via single sign-on. The web application only relies on [OIOSAML] for user authentication and does not need to be reprogrammed to support invocations from rich clients. Assumptions: The web application is SAML 2.0 compliant and supports unsolicited responses as required by the SAML Web SSO profile [SAMLProf]. There exist a common Identity Provider (e.g. Security Token Service) that is trusted by both rich client and web application. The Identity Provider can issue a SAML Assertion that will be accepted by the web application. This implies that it has to know identity (or pseudonym) and other attributes about the user required by the web application (or it can establish these using back-end token exchanges). The rich client is able to launch a browser with a specific URL for the web application. Non-goals: We do not consider transferal of application context only establishment of an authenticated session. A simple means of transferring context from the rich client to the web application could be via parameters in the start-up URL. Of course the Identity Provider can also pass context via attributes in the issued Assertion to the extent it is relevant or possible. The user authentication towards the rich client is considered out of scope. The interaction between the rich client and the Identity Provider (or any other back-end service) is considered out of scope. This includes how the rich client proves to the Identity Provider that it acts on behalf of a specific user. Note that for security reasons rich clients should not be able to request Assertions from the Identity Provider on behalf of a user they don t have a session with. The web application does not participate in single logout handshakes with the Identity Provider in case the user already has other web sessions initiated via the Identity Provider using SAML Web SSO. This means that the user will have to close the browser to close the current browser session with the application. 5

6 3 Scenario Details > This chapter shows to realize the scenario using OIOSAML as a central building block. The main steps of the scenario are: 1. The user authenticates to the rich client and begins an application session. The rich client reaches a state where a browser needs to be launched (e.g. as a result of user interaction). 2. The rich client authenticates to an Identity Provider / Security Token Service and requests a SAML Assertion to be issued for the web application (e.g. using OIO WS-Trust Profile). 3. The rich client launches a browser with a special start-up URL containing a SAML unsolicited response message carrying the issued SAML Assertion. 4. The browser sends the SAML unsolicited response message to the web application (see below). 5. The web application validates the assertion, and if validation is successful creates a local session with the browser (e.g. using browser cookies). The web application returns the content identified by the URL to the browser. Figure 2: Scenario steps 3.1 Unsolicited Response Messages In the SAML Web SSO Profile [SAMLProf] the term unsolicited response is used to describe a scenario where the Identity Provider initiates a Web SSO flow by sending an unsolicited SAML <Response> message to a Service Provider (i.e. web application). In other words, the web application gets a SAML <Response> message even though it did not request authentication from the Identity Provider - thus effectively bypassing the first steps of the normal SAML Web SSO protocol. 6

7 > According to [SAMLProf] a SAML compliant Service Provider SHOULD be prepared to handle unsolicited responses so this feature is expected to be generally available in SAML implementations. The Assertion delivered in the response is just a plain OIOSAML Assertion. 3.2 Selecting Protocol Binding The SAML Assertion must be delivered using a binding accepted by the web application (Service Provider). According to OIOSAML, applications are required to support HTTP POST binding, so this binding will generally be available. One of the main advantages of the POST binding is that is does not have limitations in the amount of data that can be transferred, as is usually the case with HTTP GET operations. However, on some client platforms it can be difficult to reliably launch a browser process that performs a POST operation without getting browser warnings etc. In these cases the HTTP Redirect binding can be used if the application supports it, or as an alternative one can introduce an additional step where the browser first just gets a short-lived secret 1 (e.g. a GUID) in the start-up URL, and then contacts a web server to exchange the secret for a page that can deliver the unsolicited response to the application using HTTP POST as shown in the figure below: Figure 3: Exchanging a secret for a form POST 1 Note: HTTPS shall be used to encrypt all traffic between browser and web server. The secret should be short lived (e.g. 1 minute), be impossible to guess (high entropy) and checks must ensure that it can only be used once. 7

8 > In the figure, the Identity Provider offers an additional endpoint (e.g. web server) used to exchange a one-time, short-lived secret for a page that can POST the SAML <Response> message, but in principle it could be located elsewhere. Note also that the additional (proprietary) step is invisible to the web application it is encapsulated in the contract between the rich client and the Identity Provider. 8

9 4 Appendix A: References > [OIOSAML] [OIOIDT] [SAMLCore] [SAMLProf] OIO Web SSO Profile version 2.0.7, IT- og Telestyrelsen. OIO SAML Profile for Identity Tokens 1.0, IT- og Telestyrelsen, Assertion and Protocols for the OASIS Security Assertion Markup Language 2.0, OASIS Standard os.pdf Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard os.pdf 9

10