Prerequisite: Completion of Lab 4.
In this lab, you’ll add support for federation using Security Assertion Markup Language (SAML). SAML is an XML-based standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions).
In the context of Web services, SAML is used primarily for federation. The consumer of a Web service will authenticate a user and create a digitally signed SAML assertion on that user’s behalf. The digital signature assures that the assertion is not modified on its way to the service provider.
At the service provider, the digital signature is verified using a validation credential (which could contain many client certificates). If the signature is valid and the assertion hasn’t expired, the request is accepted as authenticated.
In this lab, you’ll create a federated environment that will use an XML Firewall as the client, and the web service proxy that you created in this lab as the service provider. The following diagram illustrates how a request will be processed.
In the preceding illustration, the following sequence of events occur:
● The service consumer (soapUI on your workstation) will submit a SOAP request which contains a WS-Security UsernameToken.
● An XML Firewall acts as the outbound federation point for the consumer. It first
authenticates the client by extracting the credentials from the UsernameToken, and then authenticates them against an LDAP server. If this succeeds, the AAA policy will generate a signed SAML assertion and forward the message to its intended service endpoint (the WS-Proxy E6BService that you created earlier in this lab).
● The message is received by the WS-Proxy which looks for the signed SAML assertion. If it does not find it, it rejects the request. If it is found, and the signature is valid, then it will allow the request to pass through to the actual E6BService.
5.1.1 Modify the AAA Policy to add a SAML Authentication Assertion
Previously you created an AAA policy that extracts the user and password from a WS-Security
UsernameToken element and authenticates against a remote LDAP server. In the next few steps, you’ll modify that policy so that if the authentication succeeds, it will add a SAML authentication assertion to the original request. You’ll also specify which private key and certificate to use to sign the assertion.
This AAA Policy is for the Federated Partner
The partner is responsible for authenticating the request before they send it to the consumer. This AAA policy will authenticate the request against an LDAP, create a SAML assertion, sign the assertion, and forward the request to the service provider.
__1. In the left navigation menu, expand the Objects menu; then locate the XML Processing section and click on the AAA Policy link.
__2. Click on MyAaaPolicy to open the configuration form.
In an earlier lab, you uploaded the partner’s certificate (for use in SSL). Since this AAA policy must sign the SAML assertion with the partner’s private key, you’ll now have to upload the private key and create a Crypto Key object.
__3. In the SAML Message Signing Key field, click the plus (+) sign to create a new Crypto Key.
__4. In the Configure Crypto Key form, use the following values:
__a. In the Name field, type: PartnerKey
__b. In the File Name field, click the Upload button.
__c. Click the Browse button, and browse to the labs/lab5 directory and select: partner-privkey.pem.
__d. Click the Upload button.
__e. Click Continue to dismiss the confirmation window.
__f. In the Configure Crypto Key form, click the Apply button to save the new crypto key.
__5. In the SAML Message Signing Certificate dropdown, select: PartnerCert
__6. Click the PostProcessing tab at the top of the form.
__7. For Generate SAML Authentication Assertion, click: on __8. Click the Apply button.
5.1.2 Create the Web Service Consumer
For this step, you’ll create an XML Firewall service that will authenticate requests using the same AAA Policy that you created earlier, except you’ll modify the policy to add a signed SAML authentication assertion to the request.
__9. Click on the Control Panel link.
__10. Click on the XML Firewall service icon to start the creation process.
__11. Click the Add Advanced button.
__12. In the Configure XML Firewall form, specify the following details:
__a. Firewall Name: MyPartner __b. Server Address: E6BServer
__c. Server Port: 445nn (where nn is your student number)
__d. Front End Device Port: 555nn (where nn is your student number) __e. Response Type: Pass-Thru
__13. In the Firewall Policy field, click the plus (+) button to create a new policy.
__14. In the Policy Editor, specify the Policy Name as: MyPartnerPolicy __15. Click the New Rule button to create a new rule for this policy.
__16. In the Rule Direction dropdown, select: Client to Server
__17. Double click the yellow outlined match action to open its configuration page.
__18. In the Matching Rule dropdown, select: MatchAnyURI __19. Click the Done button.
__20. Drag an AAA action onto the processing rule.
__21. Double click the yellow outlined AAA action to open its configuration page.
__22. In the AAA Policy dropdown, select MyAaaPolicy __23. Click the Done button.
__24. Click the Apply Policy button to save the new policy.
__25. Click the Close Window link to close the policy editor.
__26. Click the Apply button to save the XML Firewall configuration.
5.1.3 Create the SAML AAA Policy
The AAA policy you just modified will be executed by the service consumer (partner) before sending the request to the service provider. The service provider will need an AAA policy that looks for a signed SAML assertion as its authentication credentials. You’ll create the AAA policy in the next steps.
__27. In the left navigation menu, under the Objects menu, XML Processing section, click on AAA Policy.
__28. Click the Add button to create a new AAA policy.
__29. For the Name field, type: MySamlPolicy
The request will contain a SAML assertion signed by the partner with PartnerKey. The PartnerCert is used to verify the signature. In an earlier lab, you created a validation credential that contained
PartnerCert. This AAA policy will use that validation credential to verify the digital signature on the SAML assertion.
__30. In the SAML Signature Validation Credential, select: MyValcred __31. Click on the Identity tab at the top of the form.
__32. For Methods, select: Name from SAML Authentication Assertion __33. Click on the Authenticate tab at the top of the form.
__34. In the Method dropdown, select: Accept a SAML Assertion with a Valid Signature __35. Click on the Resource tab at the top of the form.
__36. For the Resource Information, select: Local Name of Request Element __37. Click the Apply button.
The final steps are to add the new AAA Policy to the E6BService. For this exercise, you’ll add the AAA policy to the CalculateFlightLeg operation.
__38. Click on the Control Panel link at the top of the left navigation pane.
__39. In the left navigation pane, click on the Services menu.
__40. In the Web Service Proxy section, click on: Edit Web Service Proxy.
__41. Click on E6BServiceProxy.
__42. Click on the Policy tab.
__43. In the Web Service Proxy Policy section, click on: Open tree to Operations. This will show all of the operations in the service.
__44. Scroll down and locate the CalculateFlightLeg operation. Click the Add Rule button.
__45. In the Rule Direction field, select: Client to Server __46. Drag an AAA action after the match action.
__47. Double Click the yellow outlined AAA action to open its configuration page.
__48. In the AAA Policy field, select: MySamlPolicy __49. Click the Done button.
__50. Click the Apply button to save these configuration changes.
5.1.4 Testing SAML Federation
In these last steps, you’ll submit several requests to the E6BService to show that the SAML-based federation is effectively working.
First, you’ll verify that you can no longer execute the CalculateFlightLeg operation without a SAML assertion.
__51. In soapUI, under the CalculateFlightLeg operation, double click on Request 1 to bring it up again.
__52. Make sure there is no Username, Password, or WSS-Password Type specified in the Request properties.
__53. In the endpoint dropdown list, make sure that http://datapower:445nn/E6BService/E6BService is selected.
__54. Click the green submit button to execute the request. It should fail with a SOAP fault: Rejected by Policy. It is failing because the policy now requires a signed SAML assertion and there isn’t one.
Now you’ll post a message to the XML Firewall that represents the partner consumer. Again, do it without a username and password so that you can see that it is enforcing the need for a WS-Security
UsernameToken.
__55. In the dropdown endpoint, select the partner service (XML Firewall) that is listening on port 555NN, and then edit it so the port correctly shows your student number. For example, student01 should show port 55501.
__56. Click the green submit button to post the request to the XML Firewall (partner).
The request should fail since the partner’s AAA policy is expecting to extract the username and password from a WS-Security UsernameToken.
Finally, submit the request with the username and password. The request will pass authentication in the partner service, which will then create a signed SAML assertion and forward the request to the WS-Proxy that’s protecting the real web service. The WS-Proxy will consume the signed SAML assertion and permit the request to go through.
__57. In the Request Properties section in soapUI, specify the following properties:
__a. Username: david __b. Password: foobar
__c. WSS-Password Type: PasswordText
__58. Once again, click the green submit button. This time, the request should succeed.
If the request was successful, you can use the probe to see the various stages of the message. The complete flow is as follows:
● Request is generated by SoapUI (representing the partner). Request contains username and password in WS-Security UsernameToken.
● Before the request is sent to your service over the Internet, it will hit a an XML Firewall that will authenticate the outbound request by extracting the username and password from the WS-Security UsernameToken and binding to an LDAP. If this is successful, the XML Firewall will generate a digitally signed SAML Authentication Assertion and insert it into the SOAP header. It will then forward the message out over the public Internet to your E6BService.
● The E6BService is protected by a WS-Proxy service which contains an AAA policy that looks for the signed SAML assertion. The AAA policy will attempt to verify the digital signature of the SAML assertion, and if successful, will permit the message to flow to the actual E6BService. If the signature fails verification, the AAA policy will reject the request.
You can see all these pieces in action using the probe. The probe should still be enabled for the E6BServiceProxy. You can enable the probe for the XML Firewall which represents the partner. Flush the probe to make it easier to see the transactions, then post another request. Use the probe to inspect the partner’s outbound message before and after the XML Firewall policy executes, and to see message as it arrives into the E6BServiceProxy’s policy. With the probe, you can see the added the SAML
assertion.
__59. If your configuration is working properly, click the Save Config link in the upper right corner of the window to save your configuration to the flash memory
5.2 Summary
In this lab, you saw how WebSphere DataPower can participate in a federation using SAML by by creating a mock environment for SAML-based federation. You created an XML Firewall with an AAA policy that authenticates the user against an LDAP and then generates a signed SAML assertion. Then you created a new AAA policy that looks for a signed SAML authentication assertion.