1<<if: ZXIDBOOK>> 2<<else: >>ZXID Integration Guide for TAS3 3########################## 4<<author: Sampo Kellom�ki (sampo@symlabs.com)>> 5<<cvsid: $Id: zxid-java.pd,v 1.4 2009-08-30 15:09:26 sampo Exp $>> 6<<class: article!a4paper!!ZXID-JAVA 01>> 7<<define: ZXDOC=ZXID Java Interface>> 8 9<<abstract: 10 11ZXID.org Identity Management toolkit implements standalone SAML 2.0 and 12Liberty ID-WSF 2.0 stacks. This document describes how to use ZXID to 13implement the TAS3 architecture. 14 15>> 16 17<<maketoc: 1>> 18 191 Introduction 20============== 21 22TAS3 (http://www.tas3.eu/) is an advanced architecure for web services 23ecosystems. ZXID has an implementation of the most of the core 24technologies required to build TAS3 compliant systems. This doecument 25describes how this is to be done. 26 27> *Acknowledgement*: The research leading to these results has 28> received funding from the European Community's Seventh Framework 29> Programme (FP7/2007-2013) under grant agreement number 216287 (TAS3 30> - Trusted Architecture for Securely Shared Services - www.tas3.eu). 31 321.1 Other documents 33------------------- 34 35<<doc-inc.pd>> 36 37<<fi: >> 38 392 TAS3 Integration Strategies 40============================= 41 422.1 TAS3 Proxy 43-------------- 44 45In TAS3 Proxy strategy, the legacy application is not modified at 46all. Instead it is shileded by a proxy that will handle TAS3 related 47identity management, seucrity, and authorization aspects and 48then call the legacy application. If the legacy application needs 49to call TAS3 compliant web service, it makes the call against 50the TAS3 Proxy, which will add TAS3 related features and then 51call the real web service, wait for result, and process TAS3 52aspects of the result. 53 54Main complexities of the TAS3 proxy approach arise when 55some of the identity information needs to be passed from 56the proxy to the legacy application (and from legacy app to 57the proxy in case of web services client). Generally this 58tends to involve awkward and nonstandard methods or keeping 59a session and passing reference to the session so that the 60legacy app can obtain the needed information from the session. 61 62Whereas the main attraction of the TAS3 Proxy integration strategy is 63that there is no API for the legacy app to call, the complications 64with the information passing still seem to necessitate an API and 65some TAS3 awareness on part of the legacy app, thus negating the 66main benefit of the proxy approach. 67 68Three cases need to be considered. 69 702.1.1 TAS3 SSO Proxy (front channel) 71~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 72 73Needs to establish a session, extract attributes and bootstraps 74from the SSO assertion, and pass session id to legacy app. 75 76The session ID is most conveniently passed has HTTP-Header "Cookie" 77where the legacy app then needs to use it in the customary way to 78access the session. ZXID does not currently (2009) support any 79platform specific session systems, but built-in JSESSION 80support could make those specific types of integration simpler. 81 82Another possible approach is to pass the identity 83of the user directly as Authorization header conveying HTTP 84Basic Authentication parameters (where password field is just 85ignored). This is similar to REMOTE_USER trick we will see 86in the mod_auth_saml. Session cookie and basic authentication 87can be combined. 88 892.1.2 TAS3 WSC Proxy 90~~~~~~~~~~~~~~~~~~~~ 91 92Adds TAS3 headers to SOAP request and sends the request to the real destination. 93 94Processes TAS3 response, making authorization checks, and returns the response 95to the legacy app. 96 97The information on whose behalf the call is being made is passed by 98passing the session ID as Cookie so that the TAS3 WSC Proxy 99can lookup user identity information for inclusion to the message 100headers. The TAS3 WSC Proxy is also responsible for any discovery 101activity, if needed. 102 1032.1.3 TAS3 WSP Proxy 104~~~~~~~~~~~~~~~~~~~~ 105 106Processes and authorizises the SOAP request and then sends it to the 107legacy app, passing identity information along. Decorates the 108response and returns it to the caller. 109 110Identity information is passed to legacy app in form of faked basic 111authentication and cookie carrying the session ID. 112 1132.2 Apache Module Approach (mod_auth_saml) 114------------------------------------------ 115 116This approach is similar to proxy approach in that the legacy app does 117not need to call any API, but differs in that TAS3 processing simply 118happens in the same Apache httpd process as serves the legacy application 119pages. 120 121The Apache module approach is not very amenable to WSC enablement. For WSC either 122proxy approach or API approach needs to be used. 123 124mod_auth_saml currently implements the module approach to SSO. It is foreseeable 125that mod_auth_saml could be extended to support TAS3 WSP as well. 126 1272.3 Servlet Approach 128-------------------- 129 130The servlet approach is similar to mod_auth_saml approach in that the 131legacy application generally does not require modification. It is 132also similar in that it focusses on frontend SSO and authorization. 133It offers little by way of actual web service call or web service 134responder implementation, but can be complemented with the Filter 135approach for these tasks. 136 137For more detail about servlet approach, see zxid-java.pd, section 138"Java Servlet Example Using Tomcat". 139 1402.4 Filter Approach 141------------------- 142 143In the filter approach, the TAS3 API calls are hooked in to the web service 144processing environment without modifying the actual legacy app. This approach 145tends to work well for Java Application Servers and Frameworks that 146have built in concepts of filters and interceptors. 147 148* *** Name the filter technology for servlets (WSP) 149* *** Name the filter technologies for clients (WSC) 150 151The filter approach only works on those platforms where the concept is 152available. Such concept is generally not available on the front channel, 153i.e. filter is seldom applicable to SSO. 154 1552.5 API Approach 156---------------- 157 158In the API approach the legacy application is simply modified to call the 159TAS3 APIs where appropriate. 160 1613 ZXID APIs for TAS3 162==================== 163 1643.1 SSO 165------- 166 167* zxid_simple() API as complete solution 168* Java wrapper which allows registration of callbacks for session and 169 *** Custodix, Sym collaboration to supply 170* Alternatively: by steps approach 171 1723.2 Authorization 173----------------- 174 175* Implicit authorization steps in zxid_simple() SSO 176* zxid_az() family 177* Appication Independent PEP configuration to process 178 data items. 179 1803.3 WSC 181------- 182 183* zxid_simple_call() family 184 - String based approach to the SOAP Envelope and Body 185 - Can specify URL and use Discovery (or STS) to obtain the token 186 1873.4 WSP 188------- 189 190* *** functions for parsing SOAP messages 191 192 zx_prepare_dec_ctx(cf->ctx, zx_ns_tab, qs2, qs2+cl); 193 r = zx_DEC_root(cf->ctx, 0, 1); 194 195* *** functions for checking TAS3 SOAP headers and signatures 196 - Message signature validation 197 - Token validation 198 - Target audience check 199 200* *** functions for TAS3 decorating response 201 - zx_EASY_ENC_SO_e_Envelope(cf->ctx, env); 202 2033.5 Auxiliary 204------------- 205 206* zxid_add_attr_to_ses() 207* zxid_add_qs_to_ses() 208 2098 TAS3 Demo 210=========== 211 212 213http://sp.tas3.pt:8080/zxidservlet/zxidHLO?o=E 214http://sp.tas3.pt:8080/zxidservlet/appdemo # Protected content 215http://sp.tas3.pt:8080/zxidservlet/sso?o=E # mod_auth_saml sso 216 217mini_httpd -p 8081 -c 'zxid*' 218 219http://idp.tas3.pt:8081/zxididp?o=B 220 221<<if: ZXIDBOOK>> 222<<else: >> 223 22496 License 225========== 226 227Copyright (c) 2009 Symlabs (symlabs@symlabs.com), All Rights Reserved. 228Author: Sampo Kellom�ki (sampo@symlabs.com) 229 230See file COPYING for complete information. 231 232<<references: 233 234[SAML2core] "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", Oasis Standard, 15.3.2005, saml-core-2.0-os 235 236 237>> 238 239<<doc-end.pd>> 240<<notapath: TCP/IP a.k.a xBSD/Unix n/a Perl/mod_perl PHP/mod_php Java/Tomcat>> 241<<EOF: >> 242<<fi: >> 243