Discovery data feed for Eid 2.0

Transcription

1 Discovery data feed for Eid 2.0 Proposal for a generic discovery solution for Eid 2.0 Stefan Santesson, 3xA Security AB Summary E- legitimationsnämnden in Sweden are preparing for a new infrastructure for identification and electronic signatures (Eid 2.0). A test infrastructure is put into place (Testbädden för Eid 2.0) where participants can test implementations and contribute to technical specifications. One area that needs to be determined for Eid 2.0 is the way to handle IdP discovery. This document outlines such proposal. The solution proposed in this document has been implemented and tested. Currently, this solution for Idp discovery is fully integrated in the test SP service located at The proposed discovery data feed service is available at Background SAML discovery service The use for a 3 rd party discovery service according to the SAML discovery service protocol has its advantages and disadvantages. A great disadvantage is that the discovery service introduces one more web page (dialogue) that the user needs to visit on login and that this dialogue also may introduce a whole new look and feel than the service provider and the identity provider web pages. A great advantage is however that the discovery service is a common service with which the user may get/set a cookie to remember the choice of Identity provider across multiple services. That is, when a user selects an identity provider for login to one service, this choice can be stored in a cookie and become the preferred choice also when the same user wants to login to another service using the same common discovery service. The advantages and disadvantages with a local integration of IdP discovery at the local Service Provider is opposite. The advantage is that it provides the user with a homogeneous user experience as the IdP selection process can be integrated in the SP web service. The disadvantage is that this choice is hard to store with the user in a way that can help the user make the same IdP choice at another SP with a local discovery implementation. Local discovery feed at the SP Service provider applications used to integrate SAML authentication with an SP service, such as the Shibboleth SP application, provides a local discovery data feed that can be accessed from a login page using Ajax requests. The provided data in the

2 feed is extracted from a local cache of the federation metadata. In the Shibboleth case, this discovery data is provided as JSON data that can be imported and used in a browser web page using a simple JavaScript. Following the user s selection of IdP based on the available choices of Identity provider services, the user s web browser can remember the choice of IdP across multiple sessions by setting a cookie. The problem here, as noted above, is that this cookie by default is not useful when the user visits a service in another domain. Common discovery feed. One way to overcome the limitation of a local SP based discovery service that allows a user to remember the choice of Identity provider across multiple services, is to use a common discovery feed, which is provided as a common service to support all SP services in the federation. This will allow the user to set a cookie with the common discovery service and thus remember the choice of IdP across all SP services. However, in order to accomplish this, the solution must be designed to overcome some challenges, in particular the same origin policy enforced by common browsers. The same origin policy It is common to import data to a web page using Ajax (Asynchronous Java and XML), which in the case of discovery feeds, often is obtained in JSON format (instead of XML). However, browsers impose the same origin policy on Ajax requests for data. That is, the source of Ajax data must origin from the same domain (and use the same protocol) as the web page requesting the data. To request Ajax data from a service located in domain that is different from the domain of the SP providing the login web page, violates the same origin policy and is prevented. This effectively prevents any use of Ajax requests for discovery data in JSON form from a shared discovery service. Solving the same origin policy problem with JSONP One common way to circumvent this limitation is to use JSONP (Padded JSON). JSONP takes advantages of the fact that the same domain policy only applies to requests for data, but does not apply to import of JavaScripts from sources in other domains. JASONP therefore solves this problem by packaging data inside a JavaScript. While this may sound complicated, it is made very easy in practice through common libraries such as the jquery JavaScript library, which provides easy implementation of JSONP based data retrieval from sources outside of the web page document domain. JSONP format It is very easy to convert JSON data to JSONP. For example, if the JSON data is: { name : Carl The JSONP version of this data is: callbackfunctionname ({ name : Carl ) The name of the callback function callbackfunctionname can be arbitrarily chosen but must be unique within a session to enable the JavaScript to identify what data that is associated with each request.

3 Making a request for JSONP data is very easy in practice when using jquery, since jquery generates a random callback function name for every data request. A typical jquery AJAX request for JSON data may look like: $.getjson( urltodatasource', function(json) { //Code to handle the json data ); The $.gtetjson function normally gets the requested data using AJAX. However, by adding a callback=? query parameter to the URL, jquery alters the request from AJAX to an Http GET of a JavaScript that holds JSONP padded data. Jquery generates a random callback name (replacing the? ) and then uses this callback function to retrieve the data. All that needs to be done to alter the jquery JavaScript above to obtain the same JSON data through a JSONP request, is the following: $.getjson( urltodatasource?callback=?', function(json) { //Code to handle the json data ); The exact same JSON data is obtained in both examples. The only difference is that we are no longer restricted by the same origin policy with regards to the location of the data source when using JSONP. The server side implementation is almost as simple. The only thing the server side must do does in addition to a normal Ajax response of JSON data, is to read the callback function name from the URL query string in the Http GET request and wrap the JSON data behind that callback name, enclosed in parenthesis (as illustrated above). An example of such server side logic implemented inside an HttpServlet is: protected void processrequest(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { String callback = request.getparameter("callback"); if (callback!= null) { String jsonp = callback + "(" + getjsondata() + ")"; response.getwriter().write(jsonp); Where the getjsondata( ) function obtains the actual JSON content.

4 Proposed solution for Eid 2.0 A solution is proposed for Eid 2.0 where service providers obtains discovery data from a common JSONP discovery data feed: Login&page&from&SP&1& H:p'exchange'(web'pages'and'AJAX'data)' Service' Provider'1' Discovery'data' JSON'feed'(op6onal)' JSONP'Discovery'' data'and'cookies' Login&page&from&SP&2& JSONP'Discovery'' data'and'cookies' JSONP' discovery'data' feed' Metadata' Discovery'data' JSON'feed'(op6onal)' Federa6on' Metadata' H:p'exchange'(web'pages'and'AJAX'data)' Service' Provider'2' Requests The proposed JSONP discovery data feed offers two request functions: 1. Request for discovery data 2. Request for discovery cookie Session flow A typical session flow involves the following steps: 1. Get login page: The user loads a login web page from the service provider. This web page contains java script that implements the following steps. 2. Request discovery data: A request for discovery data is sent to the common JSONP discovery data feed by a JavaScript in the login page. The users cookie information about previous IdP choices is sent with the request. The response holds JSONP formatted data with two main components: a. Information about the users previous choice of Identity provider based on the cookie sent in the request. b. Information about all available Identity providers.

5 3. Update the IdP selection dialogue: The IdP selection dialogue is updated with the available IdPs listed in the discovery data where the user s previous choice of IdP is presented as the default choice. 4. User requests login: The user requests login with the selected Idp. 5. Set IdP selection cookie: Before sending the user to the selected Identity provider, The sends a new JSONP request to the discovery feed with information about the selected IdP. The server returns a cookie with information about the IdP selection. 6. User authentication: The user is transferred to the selected IdP for authentication. Request format Requests are sent to the JSONP discovery feed using Http Get and parameters of the request are sent as an URL encoded query string using the following fields and values: Field Values Description action discofeed Specifies a request for discovery data setcookie Specifies a request for a cookie holding the entityid of the selected IdP source URL to external source of JSON discovery data This is an optional field that only is relevant in a request for discovery data. Absent this field the JSONP server will construct the discovery data from the federation Metadata. If this field is present the specified URL are used to request JSON discovery data from the maxage Number of days until the requested cookie expires specified source. If this field is absent the cookie will be sent as a session cookie that will expire at the end of the session. This field is only relevant in requests for a cookie. callback? This field specifies the name fo the callback function in the response JavaScript and is required in all requests. The value must be unique for every data request. When this field is specified in a jquery $.getjson function, the value is set to? in order to auto- generate a random value. Example: The following is examples of typical requests to a JSONP discovery feed located at A standard request for discovery data (generated by jquery):

6 A request for discovery data where the <DiscoFeed_JSON> part of the discovery data is obtained from an external source, in this case from : eid2.3xasecurity.com/shibboleth.sso/discofeed&callback=? A standard request for a cookie, specifying that the slected IdP has the entityid : //idp.test.eid2.se/idp/shibboleth&maxage=100&callback=? Note: In all these examples the name of the callback function is set to?, which is the standard value in a jquery $.getjson request that will cause jquery to replace? with a unique value. The actual URL query string value sent to the server may look like this: callback=jquery _ This value must be unique for each request. Response format The discovery data response format uses the following main objects: Object JSONP data Extended_JSON DiscoFeed_JSON IdP_data_object DisplayName Content Callback_name(<Extended_JSON>) { last : [ entityid : <entityid value>], discofeed : <DiscoFeed_JSON> [<Array of IdP_data_object>] { entityid : <entityid>, DisplayName : [<Array of DisplayName>] { value : <display name>, lang : <ISO language code> Note: If no information about the user s previous choice of IdP is know (no cookie is provided in the request), the entityid value of last is set to an empty string. The JSON structure for DiscoFeed_JSON is compatible with the JSON format for the DiscoFeed provided by a Shibboleth SP. The format outlined above is the format used for standard responses, i.e. where the source url query string field is absent. If the source field is present, the data obtained by dereferencing the source URL is injected as the DiscoFeed_JSON data regardless of its format. This allows an SP to provide IdP data in any customized data format to the login pages obtained from the service, but to channel the data through the common JSONP discovery feed in order to allow use of the common cookie to determine the user s last IdP selection in any of the present services.

7 Example: The following is an example of JSONP data according to the default format: jquery _ ( {"last": [{"entityid": " "discofeed": [ {"entityid": " "DisplayNames": [ {"value": "NORDUnet (Test IdP)", "lang": "en" ], {"entityid": " "DisplayNames": [ {"value": "EID Testbädd Referens-IDP", "lang": "en" ], {"entityid": " "DisplayNames": [ {"value": "Kirei IDP", "lang": "en", {"value": "Kirei IDP", "lang": "sv" ]] ) Cookie response data format The important information in the response to a cookie request is the cookie itself, provided in the Http headers. Any data in the response can safely be ignored. However, for convenience, the current implementation of this proposal just returns the entityid of the selected IdP in the response data, sent in JSONP form as illustrated by the following example: jquery _ ( {"entityid": " ) Cookie The name of the http cookie set by the server the present implementation example is lastidp. The name can however be arbitrarily set by the server to any suitable name. The cookie returned by the server has its value set to the to the value of the entityid filed in the request for a cookie and its maxage set to the number of days specified by the maxage field in the request.

8 Implementation The current proposal has been implemented in a Service Provider within the test identity federation for Testbädden för Eid 2.0. The SP is located at: The JSONP discovery feed used in this implementation is located at: Client implementation The IdP discovery data and the information about previous IdP selection is used to populate and preselect a value in a select box for IdP selection in the login page. The JavaScript used to request and parse discovery data is: function getdiscofeed(){ var previous; var previdx =-1; $.getjson(' +?action=discofeed&callback=?', function(data) { previous = data.last[0].entityid; $.each(data.discofeed, function(i,idp){ entityid[i]=idp.entityid; if (entityid[i]==previous){ previdx=i; displayname[i]=idp.displaynames[0].value; // prefer names in Swedish $.each(idp.displaynames, function(j,idpname){ if (idpname.lang == "sv"){ displayname[i]=idpname.value; ); $("<option></option>").html(displayname[i]).appendto("#idpselect"); ); // Set last selected IdP as preselected value if (previdx>-1){ $('#idpselect option')[previdx].selected = true; ); The java script used to set a cookie and request user login at the selected IdP is: function idplogin(){ var i = document.getelementbyid('idpselect').selectedindex; $.getjson(' +?action=setcookie&entityid=' +entityid[i]+'&maxage=120&callback=?', function(data) { // Login window.location = Shibboleth.sso/Login +?entityid= + entityid[i] + &target= ; );

9 Server implementation The logic to parse requests in the HTTP servlet is provided by the following code: protected void processrequest(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { String action = request.getparameter("action"); if (action == null) { return; if (action.equals("discofeed")) { response.setcontenttype("text/javascript"); String json = getmetadatajson(); String sourceurl = request.getparameter("source"); if (sourceurl!= null) { json = getdiscofeed(sourceurl); String callback = request.getparameter("callback"); String jsonp = callback + "(" + getextendedfeed(json, request) + ")"; response.getwriter().write(jsonp); if (action.equals("setcookie")) { response.setcontenttype("text/javascript"); String value = request.getparameter("entityid"); String callback = request.getparameter("callback"); String maxagestr = request.getparameter("maxage"); int maxage; try { maxage = Integer.decode(maxAgeStr) * (60 * 60 * 24); catch (Exception ex) { maxage = -1; Cookie cookie = new Cookie("lastIdp", value); cookie.setmaxage(maxage); response.addcookie(cookie); String jsonp = callback + "({\"entityid\": \"" + value + "\")"; response.getwriter().write(jsonp); The external methods called in this code are: getmetadatajson( ) returns IdP discovery data in JSON form, extracted from the federation Metadata. getdiscofeed(sourceurl) returns IdP discovery data in JSON form from the external source specified by the URL query field source. getextendedfeed(json, request) returns the complete JSON data for this feed, including both information about last selected IdP (extracted from the cookie in the request) and the IdP discovery JSON data.