5.5 Experimental Results
5.5.1 Protocol Implementations Under Test
In this section we describe two implementations of the profile SP-initiated of SAML SSO, and one implementation of the OpenID protocol used with different IdPs. They are the SAML-based SSO for Google Apps, Simple- SAMLphp, and Zoho Invoice used with Google and Yahoo OpenID identity provider.
SAML-based SSO for Google Apps
The protocol implemented in the SAML-based SSO for Google Apps in op- eration until 2009 is depicted in Figure 5.2. The model has been obtained by carefully inspecting the reference implementation of SAML-based Single Sign-On for Google Apps and by experimenting with the online service.
In the implementation offered by Google, when SP receives a request for a resource URI from C, if the request is accompanied by a valid session cookie, then the resource is returned right away (step S10 in Figure 5.2). The name of the session cookie depends on the specific service considered, e.g. it is named CALHin case of Google Calendar, and GXAS in case of Gmail. If the request is accompanied by valid values for the parameters auth and husr in the URI, then SP creates a fresh session cookie and sends it back to C; C then is asked to resubmit the request by means of an HTTP redirect (steps S8 and S9). If neither of the above conditions hold, C is redirected to the Service Login (SL) and the requested URI is passed as the value of the continue URL- encoded parameter. Upon receipt of this request, SL initiates the SAML Authentication Protocol (step A1) using SL?continue=URI as the value of the aforementioned RelayState field. If the SAML Authentication Protocol completes successfully, then SL sets the cookies HID, HUSR, and ASIDAS and returns an HTML page of the form (concisely indicated as Script(. . .) in step S4 of Figure 5.2):
< html > ... <body>
< script > var url =URI . . . window . s e t T i m e o u t ( f u n c t i o n () { window . l o c a t i o n = url ; } , 0) ; </ script > . . . </body> </ html >
This simulates a redirection by setting the value of the browser variable
window.locationto URI and forcing the browser to reload the page. Notice that since the value of URI is embedded into the HTML page, it will be
5.5. EXPERIMENTAL RESULTS 107
C IdP SP
S1. GET URI
S2. HTTP200 Homepage; SetCookies(PHPSESSID,SimpleSAMLSessionID,foodleSession)
S3. GET as_login.php?ReturnTo=URI; Cookies(Session)
A1. HTTP302 IdP?SAMLRequest=AReq(ID, SP, ACS)&RelayState=URI
A2. GET IdP?SAMLRequest=AReq(ID, SP, ACS)&RelayState=URI
IdP builds an authentication assertion AA= AuthnAssert(ID, C, IdP, ACS) A3. HTTP200 Form(. . .)
A4. POST ACS?SAMLResponse=AResp(ID, ACS, IdP, {AA}K−1
IdP), &RelayState=URI; Cookies(Session)
S4. HTTP200 Resource(URI); SetCookies(SimpleSAMLAuthToken)
Legenda: : https
Figure 5.3: SimpleSAMLphp as deployed in Foodle
evaluated by the JavaScript interpreter.
SimpleSAMLphp
The protocol implemented by SimpleSAMLphp is depicted in Figure 5.3 where SP is the Foodle service offered by Uninett and available at http: //foodl.org, while IdP is the OpenIdP provided by Uninett and available at https://openidp.feide.no/.
The protocol execution starts with C asking for the resource URI to SP. In step 2, SP redirects C to an internal login service of SP. Here, between step S3 and A1 takes place the identity provider discovery protocol. The identity provider discovery protocol aims at identitifying the last IdP used by C by inspecting the cookies of C. In all our experiments, we assume that when C starts the protocol, C does not have any cookie installed. As a result the identity provider discovery protocol fails and SP shows to C a list of IdP. C selects IdP, and the SAML protocol begins. In step A1, SP redirects C to the IdP with an authentication request. The IdP challenges C and redirects C to the SP. The protocol ends with SP providing the resource to C.
C IdP SP S1. GET URI
S2. HTTP302 SP/login?serviceurl=URI
S3. GET SP/login?serviceurl=URI;
S4. HTTP200 LoginForm;
S5. POST SP/openid; identifier=IdP&servicename=ZohoInvoice
S6. HTTP302 IdP?oidAuthnRequest(C, IdP, h, SP)
S7. GET IdP?oidAuthnRequest(C, IdP, h, SP)
S8. HTTP302 SP?oidAuthnResponse(IdP, C, SP, n, h)
S9. GET SP?oidAuthnResponse(IdP, C, SP, n, h)
S10. HTTP200 Resource(URI)
Legenda: : https
Figure 5.4: Zoho Invoice relaying party service
Zoho Invoice Relying Party
Our experiments focused on the relying party provided by Zoho Invoice. Zoho Invoice is an online billing solution for small business https://www. zoho.com/invoicedeveloped by Zoho. Zoho Invoice service allows users to be registered and log in at their domain. Alternatively, users can login by using SSO protocols such as OpenID, or other protocols such as OAuth2.0. Zoho Invoice supports only two OpenID identity providers, they are Google OpenID and Yahoo OpenID. In our experiments we have focussed only on Zoho Invoice service when used with both OpenID identity providers.
Figure 5.4 shows the HTTP messages exchanged between a web browser guided by an user C, the identity provider IdP, and the Zoho Invoice service SP for accessing the front page URI=https://invoice.zoho.com/view/ZB_ Main/ZB_Invoice.
In step S1, C requests the resource URI. Then, SP redirects C to the local login service SP/login with a parameter serviceurl carrying the original resource asked by C. In step S4, the login service of SP returns the login page
5.5. EXPERIMENTAL RESULTS 109
Figure 5.5: User login at Zoho Invoice
of Figure 5.5. Afterwards, C selects to login with Google or Yahoo OpenID identity provider. As a result, SP prepares the authentication requests and redirects C to the IdP selected for being authenticated. The user is then authenticated and, in turn IdP prepares an authentication response. In step S8, IdP redirects C to SP together with the authentication response. Once SP receives the authentication response, SP provides the resource to C.