From spn at itst.dk Sun Sep 7 23:55:40 2008 From: spn at itst.dk (=?iso-8859-1?Q?S=F8ren_Peter_Nielsen?=) Date: Mon, 8 Sep 2008 08:55:40 +0200 Subject: [Sig-wsh] Danish Multi-protocol Web service use case (SAML 2.0 + WS Trust + Liberty ID_WSF) In-Reply-To: References: Message-ID: Hi, I have been asked to share a Danish eGov use case that involves a Multi-protocol Web service. Business Requirements We have identified a large potential is enabling self service solutions for citizens and private businessed applying to a public sector institution for grants, permit etc. Today most public sector processes to handle grants are manual og semi-manual. Generally, an application includes the following steps - The applicant fills out an application, and delivers supporting documentation. Often the suporting documentation is information that the public sector already has, but it is not available to the authority handling the application - Thus the applicant has to collect the documentation and supply it in paper based form. - The Case handler formally receives the application and checks whether it is valid - Often there are errors in the application which then goes back to the applicant for correction and resubmittal - Once the application is valid the public sector case handler then must verify the supporting documentation. For each piece of documentation the case handler must contact a public sector servant in the relevant authority and ask them to verify the supplied documentation. - After the validation which can take weeks the case handler can process the application which then may need several layers of approval before a response is given to the applicant. The above process can be automated, and thus result in drastic saving in the time public sector servant has to spend on each application, and also give the citizen/private business a much faster reply on their application. This can be accomplished by creating an "application-portal" that can assure that an application is valid before formally submitting it. This includes that the "application-portal" know which supporting documentation is needed for an application, and has web service access to those public sector authorities storing the information. Due to data privacy considerations the web services requests to the different public sector authorities must be done with the applicants own identity. Many of the public sector data-services are relevant in many different application processes, and must thus be able to supply an interface to many different web service consumer. Further they may also be able to support situations where the data in question are so sensitive that it is not enough to have a trusted service to vouch for the applicants identity - so there must be an ability for the data service to request direct interaction with the user to have them confirm that a certain dataset indeed is to be released. I have a presentation with further details about a specific self service process, as well numbers regarding the potential in automating the many manual application processes going on today in the public sector - Let me know id you want me to share this. Infrastructure Implementation The applicant will access the self service application via web browser, and it will in turn make web service requests to the data services. We have an existing SAML 2.0 based Web SSO infrastructure (using our OIOSAML 2.0 profile), so the user will arrive at the self service application with a SAML 2.0 assertion. It seems natural to utilize the Liberty ID_WSF framework to handle the web services interaction with the data services. It is specified to a level that assures interoperability, and ID_WSF support a lot of use cases that are very relevant - also for more advance eGov scenarios. On the other hand we have some public sector authorities that are in the process of deploying a WS-* based architecture including security token services for their own business applications. We also have a large part of our developer base that easily grasp the "simple" concept of a security token service, and prefers to develop using this concept rather than learn the full Liberty ID-WSF framework. We cannot ignore this as developer acceptance is critical for accelerated deployment - On the other hand we do also want to be able to utilize the good thinking that has gone into ID-WSF as the authorities matures and their requirments grow. Further we have an overarching goal of consolidating "mature" integration forms to aid in driving deployment - and thus a better integrated public sector. To support these different requirements we need to have interoperability on a certain level between ID-WSF and WS-*. Specifically, we look at supporting the following 3 step process 1) The users "identity" is supplied to the web service consumer (the self service application) 2) The web service consumer takes the users "identity" and has a trusted source turn it into a security token that can be used in a request to a data service 3) The data service get the request, and either accept it as the user itself requesting the data due to its relationship with the "trusted source" or requests direct interaction with the user We will do the following 1) We will utilize the Liberty concept of including a "Bootstrap" tolken in the users Web SSO SAML 2.0 assertion 2) In this step the web service consumer should be able to use a Security Token Service or a Liberty Discovery service to get a security Token 3) For the actual SOAP web service request a "basic" profile of Liberty ID-WSF is used With this approach we can assure interoperability without mandating public sector authorities putting unnecessary restrictions on how they can evolve their solution portfolio. However, to support this we need the mentioned "basic" profile of ID_WSF, We need a WS Trust profile where a SAML 2.0 bootstrap token can be taken as input, and a SAML 2.0 Holder-of-Key token can be delivered that can be used by the "basic" Liberty profile. We see that we can use the profiles mentioned above generally - and not just for the self service scenario. Currently we are also working with the Health and B2G Sector to make sure their requirements are covered as well. A few requirements going back to the vendors we see to really drive deployment longer term is that their infrastructure components and development tools should be able to support our profiles. A few examples: Out-of-the-box STS'es should support Holder-of-Key Subject Confirmation with an asymetric key supplied by the web service consumer, The development tools should have enough support so that suporting the profiles simply is a question of configuration - Having to use an extra toolkit is an obstacle because as soon as you need more than one toolkit then two toolkits may be incompatible,... We are currently doing Proof-of-concept work on the above, we are working with the Liberty TEG regarding the "basic" profile, we have taken a lot of good input from Chad La Joie/the SWITCH federation regarding the WS Trust client profile, but we certainly welcome further input an advice on this - and we are also happy to give further information about our requirements, finding etc. Thx. S?ren Peter Nielsen Senior Adviser IT Architect in IT Infrastructure and Implementation Division Direct phone: + 45 2567 0783 E-mail: spn at itst.dk Ministry of Science, Technology and Innovation National IT and Telecom Agency Holsteinsgade 63 DK-2100 K?benhavn ? Phone: +45 3545 0000 Fax: +45 3545 0010 E-mail: itst at itst.dk www.itst.dk