IBM SECURITY ACCESS MANAGER 9.0 IBM SECURITY IDENTITY GOVERNANCE AND INTELLIGENCE 5.2 AND. Integration CookBook

Transcription

1 IBM SECURITY ACCESS MANAGER 9.0 AND IBM SECURITY IDENTITY GOVERNANCE AND INTELLIGENCE 5.2 Integration CookBook Gianluca Gargaro Luigi Lombardi Riccardo Alessandrini Version 1.4 Apr. 2017

2 Document Control Release Date Version Authors Comments 11 November Gianluca Gargaro Luigi Lombardi Riccardo Alessandrini Version 1.0: SSO integration for ISAM 8.1.x and ISAM 9.0 and ISIG June Gianluca Gargaro Luigi Lombardi Riccardo Alessandrini Version 1.1: Tested and documented Integration with IGI 5.2, added security recommendations 18 October Gianluca Gargaro Luigi Lombardi Riccardo Alessandrini 3 March Gianluca Gargaro Luigi Lombardi 12 April Gianluca Gargaro Luigi Lombardi Version 1.2: Tested and documented Integration with IGI 5.2.1, added support for WebSocket with ISAM Version 1.3: Tested and documented Integration with IGI Version 1.4: Tested ISAM Minor changes on transformation rules. Extended ISAM troubleshooting. Added ISAM Kerberos SSO appendix. Page 2 of 60

3 Table of Contents 1 Introduction High Level Architecture Required Components Access Manager Virtual Appliance IGI Virtual appliance IGI Configuration Enabling IGI header Authentication on the Appliance Console Enabling username authentication on the IGI Central Administration console ISAM Configuration Import IGI CA certificate Create an SSL junction Defining the Login HTTP Transformation Rule Defining the Logout HTTP Transformation Rule Enabling websocket support in ISAM WebSeal for integration with IGI and Testing the integration Appendix A: Troubleshooting Appendix B Active Directory user in ISAM Appendix C Kerberos Desktop SSO to IGI Creating an identity for WebSEAL in the Active Directory Domain Map a Kerberos principal to the WebSeal Active Directory Identity Configure ISAM appliance Kerberos client Configure WebSeal instance for Kerberos Desktop Single Sign On authentication Configure browsers for Kerberos authentication Page 3 of 60

4 1 Introduction This cookbook provides a step-by-step guide to configure Single Sign On integration between IBM Security Access Manager (ISAM) 9.0 Virtual Appliances and IBM Security Identity Governance and Intelligence (IGI) 5.2.x Virtual Appliance. Earlier version of ISAM 8.0 and ISIG can also be used with almost same configuration steps. ISAM 7.0 may also work but it has not been tested. A dedicated section has been added covering integration with ISAM ( or ) and IGI and with WebSocket support. Unless otherwise documented most of the configuration steps are common to all versions of products We are not covering how to install the required components nor how to perform initial configuration. 1.1 High Level Architecture The high-level architecture for the environment described in this document may be summarized as follows: Page 4 of 60

5 The ISAM Appliance with its multiple network interfaces an IP addresses can be logically placed both in a secure area and in a demilitarized (DMZ) area with its reverse proxy WebSeal component. While the IGI appliance and all other components can be placed in a secure area. IGI desk users can reside either internally and access the IGI desk application directly or externally in the unsecure area, and access the desk application through the WebSeal proxy. It is to remark that when enabling this integration IGI has no way to verify trust relationship with ISAM WebSeal so anyone can potentially access the application interface of IGI simply making request with an iv-user header and no password. This means that when this integration is in place it is highly recommended that also internal users connect to IGI through a WebSeal instance and a direct access to IGI application interface is denied by proper network security policies in place! Here below an example of how this can be easily achieved with a browser plugin that inject iv-user header Page 5 of 60

6 1.2 Required Components Access Manager Virtual Appliance An already configured Access Manager Virtual Appliance 9.0 or 8.0 is required with at least a WebSeal instance configured with form Based authentication. For better results integration with ISIG and is done with ISAM or ISAM however earlier versions of ISAM could be used but have not been tested IGI Virtual appliance This guide assumes that an ISIG with FP 1 or IGI 5.2 or IGI or virtual appliance is configured and that the default IDEAS realm is used. Page 6 of 60

7 2 IGI Configuration This section describes the configuration of IGI 5.2.2, IGI 5.2.1, IGI 5.2 or ISIG Virtual Appliance. The configuration steps are almost the same for all the releases, however minor differences are in the name and content of the menus (on IGI 5.2 for instance the Identity Governance and Intelligence is used instead of Identity Governance, and Administration Console is used instead of Central Administration ) as well as in the usage of the SSL port 9343 by the application interface in IGI 5.2 instead of 443 that is used in ISIG When necessary appropriate differences are reported. 2.1 Enabling IGI header Authentication on the Appliance Console Login into the appliance admin console and navigate to Configure Identity Governance Manage Server Settings and click on Custom File Management Expand the directories and open the properties folder, if empty create first a desk folder and within it a console folder using the New Folder button. Page 7 of 60

8 Within the console folder upload a file named application.xml with the following content: <DESK> <REALM name="ideas" label="ideas" isdefault="true" enableheaderauth="true"/> </DESK> At the end the overall file system structure should resemble the following : NOTE : if for whatever reason you need to make any change to the application.xml file, download it, make your change in the local file, delete the file on the appliance and upload a new one. In order to delete the file on the appliance you need to delete the container folder (console) by clicking on the "Delete Folder" button, you than need to recreate the console folder enabling you to upload the new application.xml file. Page 8 of 60

9 Once the proper application.xml file is created you need to restart the IGI application. On the virtual appliance this can be accomplished by navigating to Home Appliance Dashboard selecting the Security Identity Governance server and restarting it. 2.2 Enabling username authentication on the IGI Central Administration console On the IGI Central Administration web console login using an admin account Page 9 of 60

10 and click on Access Governance Core Page 10 of 60

11 Within the Access Governance Core navigate to the Settings tab and select, if not yet enabled, the Login user ID Access option: On IGI the same Access config looks a bit different and it is necessary that the Account selected is Ideas and the Attribute is code as here reported This completes the configuration required on the IGI side. Page 11 of 60

12 3 ISAM Configuration We will now perform the required configuration on the SAM side in order to have an effective and comprehensive end-user session lifecycle controlled on WebSEAL when the user works on the IGI desk. 3.1 Import IGI CA certificate Before you can create an SSL junction you need to esnsure the backend server signer root certificate is listed among the trusted Certificate Autority in the webseal pdsrv.kdb keystore. The following procedure shows how to add the default IGI server certificate that is a self signed certificate. If theigi server certificate is not a self signed certificate you don t need to load it but instead have to add the signers, intermediate and Root CA certificates using the import feature. On the ISAM LMI console navigate to Manage System Settings -> SSL certificate On the list of certificate database select pdsrv, expand the Manage drop down menu and click on edit SSL Certificate Database Select the Signer Certificate tab and on the Manage drop down list click on Load as outlined below: Page 12 of 60

13 If using ISIG connect to the ISIG server and port 443 and add a meaningful label From IGI 5.2 the server port to use is 9343 Page 13 of 60

14 Complete the operation by clicking on the Load button, if the load operation completes successfully you will have it added in the list. As mentioned, if the IGI server certificate is not self-signed you need to use the Import feature to add the signers and the root CA in the list of signer certificates. An easy way to verify that what has been added is a valid root CA is to verify that issuer and subject dn match. Page 14 of 60

15 3.2 Create an SSL junction Once the Keystore is updated and new signer certificate made available to the WebSeal instance by restarting it you can proceed to junction creation. Still on the ISAM LMI console navigate to Secure Web Settings -> Reverse Proxy select the instance, open Manage drop down list and click on Junction Management. Click on New and select Standard Junction. Page 15 of 60

16 On the Junction tab select the Create Transparent Path Junction and use /ideas (this junction name is valid for ISIG 5.1.1, IGI 5.2 and IGI ) as Junction Point name and select SSL as Junction Type Only on IGI the name of the junction should reflect the different context root used, that is /service, so the junction creation panel will resemble the following: Page 16 of 60

17 On the Servers Tab click on New On the pop up window fill in all the required fields by adding the IGI server hostname or IP address in the Hostname field and the appropriate SSL port (e.g. 443 for ISIG or 9343 for IGI 5.2.x) in the port field. Particular attention should be paid to defining the Virtual Host field. The IGI application has a requirement that the virtual host value should match the FQDN used by the end user to connect to WebSeal. ( this is due to a check done on the host header and referrer header ) In our lab the end users connect to WebSeal using URL so we set webseal900-salinas.usa.north.america.sup as the Virtual Host value. Page 17 of 60

18 For IGI 5.2, and the server setup should resemble the following with port 9343 On the Identity Tab select the IV-USER HTTP Header Identity Information so that WebSeal will pass the iv-user header to the ISIG server for authentication This completes the junction setup. Page 18 of 60

19 3.3 Defining the Login HTTP Transformation Rule In this section, we show how instruct WebSeal to perform some URI sanity check for a better end-user single sign-on experience. This check is required because if the URI used by the end user does not contain the ISIG realm query string then the ISIG desk login form may be presented when going through the junction, despite WebSeal adds the iv-user header for the single sign-on. In order to prevent this we can leverage the flexibility of the HTTP Transformation feature of WebSeal to verify requested resources have the proper information added to the query string. Still on the ISAM LMI console navigate to Secure Web Settings -> Global Settings and click on Http Transformation Click on the new button Page 19 of 60

20 In the popup window, create a new HTTP Transformation Rules File using the Request template, providing a meaningful resource name Once saved, a new rule is created with the resource name used, however this new rule is just a skeleton of a request transformation rule and you need to add your real transformation logic inside it. Select it and click on Edit, in the popup text editor find the URI matching template Page 20 of 60

21 Replace with the following when using ISIG or IGI 5.2 or (of course use your WebSeal FQDN): <xsl:template match="//httprequest/requestline/uri"> <xsl:choose> <xsl:when test="node()='/ideas'"> <HTTPResponseChange action="replace"> <Version>HTTP/1.1</Version> <StatusCode>302</StatusCode> <Header name="location" action="add"> salinas.usa.north.america.sup/ideas/desk?realm=ideas</header> <Body>%3Chtml%3E%3C%2Fhtml%3E</Body> </HTTPResponseChange> </xsl:when> <xsl:when test="node()='/ideas/'"> <HTTPResponseChange action="replace"> <Version>HTTP/1.1</Version> <StatusCode>302</StatusCode> <Header name="location" action="add"> salinas.usa.north.america.sup/ideas/desk?realm=ideas</header> <Body>%3Chtml%3E%3C%2Fhtml%3E</Body> </HTTPResponseChange> </xsl:when> <xsl:when test="node()='/ideas/desk'"> <HTTPResponseChange action="replace"> <Version>HTTP/1.1</Version> <StatusCode>302</StatusCode> <Header name="location" action="add"> salinas.usa.north.america.sup/ideas/desk?realm=ideas</header> <Body>%3Chtml%3E%3C%2Fhtml%3E</Body> </HTTPResponseChange> </xsl:when> <xsl:when test="node()='/ideas/desk/'"> <HTTPResponseChange action="replace"> <Version>HTTP/1.1</Version> <StatusCode>302</StatusCode> <Header name="location" action="add"> salinas.usa.north.america.sup/ideas/desk?realm=ideas</header> <Body>%3Chtml%3E%3C%2Fhtml%3E</Body> </HTTPResponseChange> </xsl:when> <xsl:when test="node()='/ideas?realm=ideas'"> <HTTPResponseChange action="replace"> <Version>HTTP/1.1</Version> <StatusCode>302</StatusCode> <Header name="location" action="add"> salinas.usa.north.america.sup/ideas/desk?realm=ideas</header> <Body>%3Chtml%3E%3C%2Fhtml%3E</Body> </HTTPResponseChange> </xsl:when> </xsl:choose> </xsl:template> Page 21 of 60

22 While use the following when with IGI where the context root /ideas has been changed to /service <xsl:template match="//httprequest/requestline/uri"> <xsl:choose> <xsl:when test="node()='/service'"> <HTTPResponseChange action="replace"> <Version>HTTP/1.1</Version> <StatusCode>302</StatusCode> <Header name="location" action="add"> 902b.5.support.it/service/desk?realm=IDEAS</Header> <Body>%3Chtml%3E%3C%2Fhtml%3E</Body> </HTTPResponseChange> </xsl:when> <xsl:when test="node()='/service/'"> <HTTPResponseChange action="replace"> <Version>HTTP/1.1</Version> <StatusCode>302</StatusCode> <Header name="location" action="add"> 902b.5.support.it/service/desk?realm=IDEAS </Header> <Body>%3Chtml%3E%3C%2Fhtml%3E</Body> </HTTPResponseChange> </xsl:when> <xsl:when test="node()='/service/desk'"> <HTTPResponseChange action="replace"> <Version>HTTP/1.1</Version> <StatusCode>302</StatusCode> <Header name="location" action="add"> 902b.5.support.it/service/desk?realm=IDEAS </Header> <Body>%3Chtml%3E%3C%2Fhtml%3E</Body> </HTTPResponseChange> </xsl:when> <xsl:when test="node()='/service/desk/'"> <HTTPResponseChange action="replace"> <Version>HTTP/1.1</Version> <StatusCode>302</StatusCode> <Header name="location" action="add"> 902b.5.support.it/service/desk?realm=IDEAS </Header> <Body>%3Chtml%3E%3C%2Fhtml%3E</Body> </HTTPResponseChange> </xsl:when> <xsl:when test="node()='/service?realm=ideas'"> <HTTPResponseChange action="replace"> <Version>HTTP/1.1</Version> <StatusCode>302</StatusCode> <Header name="location" action="add"> 902b.5.support.it/service/desk?realm=IDEAS </Header> <Body>%3Chtml%3E%3C%2Fhtml%3E</Body> </HTTPResponseChange> </xsl:when> </xsl:choose> </xsl:template> Page 22 of 60

23 Due to a new requirement for the SSO with IGI and IGI one more processing rule section is necessary to instruct WebSeal to inject a header named realm. In our integration we are using the default IDEAS realm however you may use your own defined one, or in case your setup uses multiple realms, you need to add some logic in the transformation rule in order to add the proper value depending by the context. If using IDEAS realm simply change the following section with this <xsl:template match="//httprequest/headers"> <xsl:choose> <xsl:when test="header/@name='realm'" /> <xsl:otherwise> <Header action="add" name="realm">ideas</header> </xsl:otherwise> </xsl:choose> <xsl:apply-templates select="//httprequest/headers/header" /> </xsl:template> At this point you can save and deploy the changes. Page 23 of 60

24 The next step is to enable this rule within WebSeal. Still on the ISAM LIMI console navigate to Secure Web Settings > Reverse Proxy. Select the instance and expand the Manage drop down list, select Configuration and click on Edit Configuration File This will open a pop-up text editor that shows the WebSeal configuration file. Locate the [http-transformations] stanza and within it define a new resource pointing to the XSLT file created. For example: Save the configuration file and restart the WebSeal instance. Page 24 of 60

25 The next step is to enable the processing of the transformation rule for specific resources by defining a Protected Object Policy ( POP ) with specific extended attributes. From Secure Web Settings -> Policy Administration login to the policy administration console using the domain administrative (sec_master) account Page 25 of 60

26 On the task list select POP -> Create POP and create a new POP by simply defining a pop name and leaving all other options as default. Once created, select it to modify its properties Page 26 of 60

27 On the Extended Attributes tab create a new attribute by clicking on Create Use HTTPTransformation as Attribute Name and Request=isig-login as Attribute Value Click on Apply to confirm the extended attribute creation. Page 27 of 60

28 Once done navigate back to the ISAM Object Space, expand WebSEAL object and the WebSeal instance where the junction /ideas has been created. Remember that when integrating IGI the proper junction to attach is /service so depending by your version of IGI select the ideas or service object and attach the created pop. Page 28 of 60

29 So that the object space resembles the following: This completes the login-control rule setup Page 29 of 60

30 3.4 Defining the Logout HTTP Transformation Rule The ISIG desk always has a logout link available to the user. When the user clicks on the link, the ISIG session is killed and the user is redirected to the desk login form again. When integrating WebSeal reverse proxy the logout process should also remove the user session from WebSeal. In order to accomplish this without making any changes to the ISIG application it is once more possible to leverage on the flexibility and power of the HTTP Transformation rule. Still on the ISAM console, navigate to Secure Web Settings -> Global Settings and click on HTTP Transformations. Click on the new button Page 30 of 60

31 and create a new HTTP Transformation Rules File, using this time the Response template Save it and then edit again so that a text editor popup is displayed where you can replace the skeleton Header template match with the following : <xsl:template match="//httpresponse/headers/header"> <xsl:choose> <xsl:when test="@name='location'"> <Header action="update" name="location"> salinas.usa.north.america.sup/pkmslogout</header> </xsl:when> </xsl:choose> </xsl:template> The next step is to make this rule available as a resource. Once again we edit the WebSeal configuration file. Page 31 of 60

32 From Secure Web Settings > Reverse Proxy select the instance and expand the Manage list, click on Configuration -> Edit Configuration File, Locate the [http-transformations] stanza and define in it a new resource pointing to the XSLT resource file just created. For example isig-logout: Save, apply changes and restart the WebSeal instance. Page 32 of 60

33 From Secure Web Settings -> Policy Administration login on the policy administration console using the domain administrative (sec_master) account if needed On the task list select POP -> Create POP and create a new logout POP by simply defining a POP name, leaving all the other options as default. Page 33 of 60

34 Once created, edit the POP by clicking on its link name Open the Extended Attributes tab and create the HTTPTransformation Attribute Name with Response = isiglogout as Attribute Value. Page 34 of 60

35 Once the extended attribute has been created, we can proceed to attach the POP to the proper logout object. This time since we use the Attach tab within the POP itself. Click on Attach button and define the logout protected object as showed here: Notice that the correct path includes the WebSEAL object, the WebSeal instance name and the junction /ideas. As already mentioned, using IGI the junction name is /service so define the logout protected object path accordingly This completes the logout control configuration. 3.5 Enabling websocket support in ISAM WebSeal for integration with IGI and IGI and service application has been developed using Vaadin that uses Atmosphere framework for client server real time communication over WebSocket. In this case when a reverse proxy is set between the browser and the server, it is necessary that the reverse proxy is able to handle the HTTP upgrade process and tunneling the rest of the bi-directional communication between browser and server. This capability has been added in WebSeal since ISAM version. To enable WebSocket support it is enough to edit WebSeal conf file and define a number of worker-threads to handle WebSocket within the [ websocket ] stanza Page 35 of 60

36 In case a large number of concurrent users are expected to single sing on to the IGI service desk or you experience some performance issue when accessing IGI service console through WebSeal you may need to increase the number of worker threads as well as find appropriate values for the others parameters in the WebSocket stanza. This completes the WebSocket configuration. Page 36 of 60

37 4 Testing the integration At this stage you can proceed to test the integration. In order to perform to the single sign-on test you need to an ISAM user whose login id matches an ISIG user. In our case we have defined an user Jane Doe whose ISAM user id is janedoe. Page 37 of 60

38 This matches the user-id defined in IGI. This match is required because this is the iv-user header value that WebSeal will send in the junction to the IGI server to accomplish the single sign-on process. Page 38 of 60

39 So if there are valid users id defined in both places you can open a browser and go to or if using IGI Login with the ISAM user credential and you are automatically redirected to the IGI user desk area : Page 39 of 60

40 From now on the user has a session on ISAM WebSeal and a session on the IGI server. In order to logout it is possible to click on any link you find in the desk, this, thanks to the logout transformation rule, logs you out from both the IGI desk and ISAM WebSeal, resulting in the following message: This completes the integration verification. Page 40 of 60

41 5 Appendix A: Troubleshooting In case of problems with the IGI SSO authentication, the first thing to do is to check the IGI log file desk_console.log. Login on the IGI Virtual Appliance and navigate to Configure Identity Governance ->Manage Server Settings and click on Custom File Management Expand directory log in the tree, and select console download the desk_console.log (if you can't see it, increase the number of visible items or go to next page) Page 41 of 60

42 Open desk_console.log with a text viewer to verify if some error messages appear. One of the most frequently issued is an error message like the following: Nov 5, :29:24 PM WARN DESK:49 - Configuration file: '/opt/isig/ideasplatformenvcustom/properties/desk/console/application.xml' not found! Nov 5, :29:24 PM ERROR DESK:29 - Error: Authentication without userid and pwd In this case, you have to check "application.xml" is present in the correct path. ( properties/desk/console ). An error like: Nov 12, :26:10 PM DEBUG DESK:24 - login iv-user jonny on realm IDEAS Nov 12, :26:10 PM ERROR DESK:60 - Error during iv-user login [SecurityFWException]: 1 - com.engiweb.security.cache at com.engiweb.security.securitycontext.loginuserid(securitycontext.java:200) at com.crossideas.toolkit.web.gestione.auth.loginuserid(auth.java:245) at com.crossideas.toolkit.web.gestione.start.other.ivuser.execute(ivuser.java:51) means that the user-id sent with iv-user header does not exist or does not match with an IGI account Master uuid value. Page 42 of 60

43 An error like : Nov 12, :30:09 PM ERROR DESK:29 - Error: Authentication without userid and pwd means that the iv-user header is not provided within the request. In order to see what is sent by WebSeal within the request you can enable WebSEAL pdweb.debug log. This is done on the ISAM virtual appliance console by navigating to Secure Web Settings -> Manage and clicking on the Reverse Proxy link Select the proper WebSeal instance and expand Manage -> Troubleshooting -> Tracing Page 43 of 60

44 Then find the component pdweb.debug, select it and set debug Level to 2 as showed here below Page 44 of 60

45 Replicate the problem, download the trace file by selecting the component again and click on Files button This will open a new window where you can download the trace file by selecting Manage > Export Page 45 of 60

46 Open the trace file with a text editor and identify where WebSeal is sending the request to the IGI server as outlined below. Within this last request, you can notice the absence of the iv-user header :48: :00I----- thread(14) trace.pdweb.debug:2 /home/webseal/ /src/pdweb/webseald/ras/trace/debug_log.cpp:175: Browser ===> PD Thread ; fd 18; local :443; remote :4083 GET /ideas/desk?realm=ideas HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 accept-encoding: gzip, deflate, sdch accept-language: en-us,en;q=0.8 connection: keep-alive host: webseal900-salinas.usa.north.america.sup referer: user-agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ cache-control: max-age=0 upgrade-insecure-requests: 1 Cookie: JSESSIONID=0000nGx6opu_JmI8hN6_7gxU7Vn:-1; PD-S-SESSION- ID=1_2_1_7pFi5gOTUkye0IE1IQIUiNcEIyLor0ffVoztAc-jPuWupxdN :48: :00I----- thread(14) trace.pdweb.debug:2 /home/webseal/ /src/pdweb/webseald/ras/trace/debug_log.cpp:175: PD ===> BackEnd Thread ; fd 22; local :33377; remote :443 GET /ideas/desk?realm=ideas HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 accept-language: en-us,en;q=0.8 connection: close host: webseal900-salinas.usa.north.america.sup referer: user-agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ via: HTTP/1.1 isam900-salinas:443 cache-control: max-age=0 upgrade-insecure-requests: 1 iv_server_name: first-webseald-isam900-salinas Cookie: JSESSIONID=0000nGx6opu_JmI8hN6_7gxU7Vn:-1 Page 46 of 60

47 While a correct request would be like the following, with the iv-user header :22: :00I----- thread(4) trace.pdweb.debug:2 /home/webseal/ /src/pdweb/webseald/ras/trace/debug_log.cpp:175: PD ===> BackEnd Thread ; fd 23; local :34189; remote :443 GET /ideas/desk?sid=echo.browserredirect&uiid=0 HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-language: en-us,en;q=0.5 connection: close host: webseal900-salinas.usa.north.america.sup iv-user: janedoe referer: user-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/ Firefox/39.0 via: HTTP/1.1 isam900-salinas:443 iv_server_name: first-webseald-isam900-salinas Cookie: JSESSIONID=0000htfa9OZhG8PYqQn4Y_v5tfF:-1 It is likely that the absence of the iv-user header is because you forget to enable the inclusion of it in the junction checking the flag on IV-USER HTTP header: Page 47 of 60

48 When using IGI or it may happen that after authenticating to WebSeal you are redirect to logout, if this case happen verify through the pdweb.debug trace that on top of iv-user header there is also realm header. A correct integration with IGI or must have a request from WebSeal to IGI that resemble the following : :43: :00I----- thread(118) trace.pdweb.debug:2 /home/webseal/ /src/pdweb/webseald/ras/trace/debug_log.cpp:175: PD ===> BackEnd Thread ; fd 24; local :41764; remote :9343 GET /service/desk?realm=ideas HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-language: en-us,en;q=0.7,it;q=0.3 connection: close content-length: 0 host: webseal-902b.5.support.it iv-user: janedoe user-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/ Firefox/45.0 via: HTTP/1.1 isam-902b:443 realm: IDEAS iv_server_name: isig-webseald-isam-902b In case realm IDEAS header is missing you need verify that the following section has been correctly added to the login control transformation rule as reported in paragraph 3.3 explicitly for IGI or <xsl:template match="//httprequest/headers"> <xsl:choose> <xsl:when test="header/@name='realm'" /> <xsl:otherwise> <Header action="add" name="realm">ideas</header> </xsl:otherwise> </xsl:choose> <xsl:apply-templates select="//httprequest/headers/header" /> </xsl:template> Page 48 of 60

49 6 Appendix B Active Directory user in ISAM With the following steps we import an Active Directory (AD) user in ISAM user registry. The operation is not an account duplication but leveraging on the federated registry support feature of ISAM all the user and group objects in an AD will also be used by ISAM for credential verification and group membership, while the import operation simply creates the required ISAM metadata in the original ISAM LDAP registry. In this way an AD domain user, can be quickly used to login on WebSeal and then SSO to IGI desk via WebSeal junction. Consider an AD user like the one below: On the ISAM LMI navigate to Secure Web Settings -> Manage >Runtime Component Expand the Manage drop down box and click on Federated Directories Page 49 of 60

50 Click on New and define a new directory entry by filling in all required parameters as below Once saved and restarted the ISAM runtime, you can proceed to import the Active Directory user as an ISAM account. Page 50 of 60

51 To do this navigate to Secure Web Settings -> Manage and click on Policy Administration After logging in with sec_master account navigate User-> Import User and fill in the required fields as below, notice that the User Id you define must match the Master uuid attribute of the IGI account while the Registry UID is the DN of the user as it is defined in the Active Directory. At this point you have a valid ISAM User Id that can be used to login to WebSeal and then single sing-on to IGI desk. Page 51 of 60

52 7 Appendix C Kerberos Desktop SSO to IGI Following steps in appendix B it is even possible provide a seamless authentication experience by enabling Kerberos Desktop Single Sign On. In this way an Active Directory domain user could login on his workstation in the morning, open a browser whenever he needs and automatically be authenticated on the IGI service desk console. In case not all users could leverage such functionality, as for instance the users not always could login from a Windows domain connected workstation, or not all ISAM users are AD users it is possible to maintain double authentication option available, Form Based authentication and SPNEGO Kerberos. 7.1 Creating an identity for WebSEAL in the Active Directory Domain In the Active Directory Users and Computers MMC snap-in create a user that represent WebSeal instance and set password that never expires, in our case we named it webseal-isam9 7.2 Map a Kerberos principal to the WebSeal Active Directory Identity. In order to map a Kerberos Service Principal Name to an AD user you need to run ktpass command from the AD server machine. Moreover you also need to export the SPN shared secret key into a keytab that will be later imported to ISAM. The command to run may looks like: ktpass -princ HTTP/webseal900-salinas.usa.north.america.sup@USA.NORTH.AMERICA.SUP -pass Madrid00 - mapuser webseal-isam9 -out c:\webseal9.keytab -mapop set -crypto ALL -ptype KRB5_NT_PRINCIPAL Page 52 of 60

53 Above command will create a file webseal9.keytab on the AD server where you run it so this file should be later uploaded via browser to the ISAM appliance. 7.3 Configure ISAM appliance Kerberos client. Very first step to perform is to configure Kerberos client file on the appliance, this is done by opening Secure Web Settings > Global Settings > Kerberos Configuration and define the default realm matching the AD domain you want to use, in our case USA.NORTH.AMERICA.SUP Page 53 of 60

54 Open the Realms tab to configure the realms section of the corresponding Kerberos configuration file Then open the Domains tab to configure the domain_realm section of the corresponding Kerberos configuration file adding a proper translation from domain to realm Open the Keyfiles tab and import the keytab file created earlier in section 7.2 Page 54 of 60

55 At the end, you can perform an initial test to verify the Service Principal Name saved in the keytab matches the URI that will be used to connect to WebSeal. In our case the Principal Name used is HTTP/webseal900-salinas.usa.north.america.sup Page 55 of 60

56 7.4 Configure WebSeal instance for Kerberos Desktop Single Sign On authentication Once Kerberos client is configured, next step is to prepare WebSeal instance to use SPNEGO Kerberos Authentication. On the reverse Proxy instance list, select the WebSeal instance to use and click on the edit tab. This will open the configuration popup window where you need to select the authentication tab. Into the Kerberos section, select HTTPS for transport, select the keytab added earlier in section 7.3 and in the Kerberos Service Names add the SPNs that are to be used to login to WebSeal. In our case we only used Do not select use Domain Qualified Name as this option will add the domain information into the userid, resulting in an iv-user header in the format of ( in our case will result in a iv-user janedoe@usa.north.america.sup) resulting in a no match with the ISIG user ( janedoe ) Page 56 of 60

57 In order to allow also access to users who can t use Kerberos it is enough to also enable Forms Authentication for HTTPS Transport, while you can disable BA. 7.5 Configure browsers for Kerberos authentication. Each browser type may need some configuration to automatically use Kerberos during SPNEGO negotiation with Kerberos ready web server. With Firefox this is done browsing the about:config section ( quickly search for the network.negotiate option). and add a list of URIs where SPNEGO Kerberos negotiation should be used. In our example we just added usa.north.america.sup as domain URI. Page 57 of 60

58 With IE ( and Chrome who inherits IE settings ), the automatic detection of the intranet network should recognize an AD domain URI allowing SPNEGO Kerberos negotiation by default. If this does not happen, you can manually add the URI opening the advanced tab or alternatively set those URIs among the Trusted sites. Still on IE one more thing you may check is that the security level for the used zone allows for automatic logon Page 58 of 60

59 Page 59 of 60

60 At the end of the process you should be able to login on the workstation using a domain user Once logged in open a browser and access directly to IGI service desk uri. If Kerberos SSO works you will be automatically presented the user service desk console without any authentication prompt. One more thing to be aware of is that when using SPNEGO Kerberos you can never effectively log out from a server as even if you terminate an authenticated session, the next request for which an authentication is needed a new session is automatically and silently negotiated without user interaction resulting an endless session experience for the end user. This concludes the Kerberos SSO section. Page 60 of 60