• www0a67.con > Communication焖oundation?
  • Communication焖oundation?

    免费下载 下载该文档 文档格式:PDF   更新时间:2014-08-01   下载次数:0   点击次数:1
    Using?the?Tivoli?Federated?Identity?Manager? Security?Token?Service?with?Microsoft?Windows? Communication?Foundation? Neil?Readshaw,?Tivoli?Advanced?Technology?Group? Table?of?Contents? Introduction 2? Introducing WS-Trust 2? Service Requester Pattern 2? Integration Scenario 4? Integration Architecture.4? Software Versions.5? WCF Client 5? Code.5? Configuration 6? TFIM STS Configuration.7? Testing the Integration 10? Troubleshooting 12? TFIM Troubleshooting.12? WCF Troubleshooting 12? Future Work 13? Conclusion.14? Introduction IBM's Tivoli Federated Identity Manager product includes a Security Token Service (STS) that can be used to validate, transform and issue security tokens that represent identities in a Service Oriented Architecture (SOA). The OASIS Web Services Secure Exchange (WS-SX) Technical Committee defines the WS-Trust standard which defines the interface to the STS. Microsoft Windows Communication Foundation (WCF) is a standards based Web services stack that is part of the Microsoft .NET Framework. WCF provides a capability to integrate with a Security Token Service. This document will provide one pattern for integrating TFIM STS with Microsoft WCF using the WS-Trust protocol. Introducing WS-Trust The WS-Trust standard (part of the WS-Security family of standards) is the open mechanism by which: Security tokens can be validated, issued and renewed Trust relationships can be established, assessed and brokered The interaction between a component and an STS providing a WS-Trust service is shown in Figure 1. Figure 1: Interaction between SOA components using WS-Trust The RequestSecurityToken (RST) and RequestSecurityTokenResponse (RSTR) messages are fundamental to the implementation of WS-Trust. Later versions of WS-Trust (1.3 and above) also provide ways to obtain multiple security tokens in a single request. The remainder of this article assumes that the reader has some familiarity with TFIM STS and WS-Trust. For more details on WS-Trust and its implementation in the TFIM STS, see the IBM Redpaper "Propagating Identity in SOA with Tivoli Federated Identity Manager". Service Requester Pattern The IBM Redpaper "Propagating Identity in SOA with Tivoli Federated Identity Manager" describes a service requester pattern (see Figure 2) for how to integrate an STS with a service component to obtain a security token suitable for inclusion with a web service request message. The service requester pattern is used when a web service client does not natively support a security token type required by the service provider, or the identity in the security token needs to be enriched or transformed in a way that the web service client is unable to do by itself. The important point about using the service requester pattern is that the security token sent with the web service request message should be able to be consumed by the web service's security infrastructure with minimal processing. Figure 2: Service requester pattern This is the integration pattern that will be applied to demonstrate the integration of TFIM STS and Microsoft WCF. Integration Scenario The WS-Trust standard offers a lot of flexibility in how RST and RSTR messages can be formed and with what content. As a result, interoperability between different technology platforms requires that a common set of features be identified. In this section, a WS-Trust interoperability profile for TFIM and Microsoft WCF will be presented. Integration Architecture The integration architecture is shown in Figure 3. Figure 3: Integration architecture For successful use of the web service, the sequence of processing at runtime is: 1. The WCF client application creates a web service client proxy object. 2. The WCF client application obtains the username/password credentials. 3. The WCF client application sets the username/password credentials on the web service channel. 4. A web service method is invoked from the WCF client application code. 5. WCF retrieves the configuration and binding information for the web service. The binding configuration specifies that a security token issued by a TFIM STS will be included in the web service request to the web service. 6. WCF forms a WS-Trust RequestSecurityToken message and sends it to the TFIM STS using binding information retrieved from the application configuration file. 7. TFIM processes the request by invoking a trust chain in its configuration to validate the username/password credentials, map and enrich the identity data, and generate a SAML 1.1 security token. 8. TFIM returns a WS-Trust RequestSecurityTokenResponse message including the SAML 1.1. security token generated in the previous step. 9. WCF consumes the RequestSecurityTokenResponse message and extracts the SAML 1.1 security token. 10. WCF forms a web service request to the web service and includes the SAML 1.1 security token issued by the TFIM STS. 11. The web service receives the request. 12. The web service authenticates the request by validating the SAML 1.1 security token. 13. The web service processes the request and provides a response to the WCF client. The WCF client and TFIM configuration aspects are described in the next sections. Software Versions The following software versions were used to implement this scenario: Tivoli Federated Identity Manager 6.2 Fixpack 3 Microsoft .NET Framework 3.5 (including WCF 3.5) Microsoft Visual Studio 2008 WCF Client Code A simple web service client program is shown below. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Xml; using System.ServiceModel; using SimpleTrustClientTest.Sample; namespace SimpleTrustClientTest { class Program { static void Main(string[] args) { try { Service1Client s1 = new Service1Client(); s1.ChannelFactory.Credentials.UserName.UserName = "testuser"; s1.ChannelFactory.Credentials.UserName.Password = ""; // Trust all certificates – not suitable for production solution System.Net.ServicePointManager.ServerCertificateValidationCallback = ((sender, certificate, chain, sslPolicyErrors) => true); Console.WriteLine(s1.GetData(5)); } catch (Exception e) { Console.WriteLine(e.ToString()); } } } } Notice the technique used to add username/password credentials to the web service request. In a larger application, these may be solicited from the user in an interactive way. Without the TFIM STS integration, these credentials would be formed into a WS-Security Username token and sent to the web service. With the TFIM STS integration, those credentials are sent to the TFIM STS, and the security token received from the TFIM STS replaces the Username token in the web service request message. The server certificate validation callback code above is used in the test environment for this article to minimize the amount of certificate configuration for the SSL channel between the WCF client and the TFIM STS. This would not be suitable for a production environment. Configuration Most of the effort to enable a WCF client application to invoke an STS is made in the application configuration file. This abstracts the majority of the identity policy from the application developer and allows it to be made at deployment time. The listing below shows the configuration file for the WCF client application. urn:wcf In the binding for the application web service (CustomBinding_IService1) notice that the authentication mode is "Issued TokenOverTransport". This indicates that an STS will be used to retrieve a security token, and that access to the STS is protected at the transport level (i.e. HTTPS) rather than using WS-Security protection at the message level. Notice that the requested token type is specified in the issuedTokenParameters element. Also notice the Issuer element specified in the additionalRequestParameters section. This is a parameter used in matching trust module chains but is not inserted by default by WCF. The issuer element within the security element specifies the address of the TFIM STS, and additional binding information by specifying the link to additional binding information. TFIM STS Configuration In the TFIM STS, a trust module chain is configured. This article will not provide step-by-step details, but screenshots are provided and key configuration items are highlighted. Figure 4 shows the chain mapping identification. This part of the configuration is matched against attributes in the incoming WS-Trust RST message to determine which configuration in TFIM to use to process the message. The Request Type should be set to the WS-Trust 1.3 (OASIS) version of the Issue URI, because trust messages from WCF will automatically use this, if using SOAP 1.2 (see WCF configuration above). The AppliesTo address will be set by WCF to the URL of the web service being requested. In Figure 4, a regular expression is used to make the chain mapping more flexible. For example, access to the same service on different servers/ports could use the same chain mapping configuration. The Issuer address is set explicitly in the WCF application configuration. This is not a parameter that WCF uses by default, whereas its use is more common in other integration points with the TFIM STS. The Token Type is set in the WCF application configuration. Figure 4: Trust chain mapping Figure 5 shows the order, type and mode of modules that compose the module chain that will be invoked when the module chain is invoked. The validate/map/issue pattern is quite common when transforming a token. An optional inclusion might be to include an authorization module using Tivoli Access Manager (TAM) or Tivoli Security Policy Manager (TSPM). Figure 5: Trust chain identification Figure 6 shows one possible configuration for how the incoming username token will be validated, using Tivoli Access Manager. How the username credentials are validated (if at all) is not significant in this scenario. Figure 6: Username token validation One of TFIM's powerful features is the range of options for mapping and enriching identities. Lookups in enterprise directories, databases and other sources is simplified with use of Tivoli Directory Integrator. In this example, a simple XSL mapping is configured to set the AuthenticationMethod attribute required when the SAML 1.1 security token is generated. urn:oasis:names:tc:SAML:1.0:am:password Figure 7 shows the configuration of the SAML 1.1 module in 'issue' mode. The name of the issuing organization is required. SAML 1.1 security tokens may be signed, but it is not required. Remember that the lifetime settings (defaulted to 60 seconds in the figure) limit the use of the SAML 1.1 security token. However, the time window chosen should also take into consideration possible clock drift between the systems hosting the TFIM STS, the WCF client and the service that will consume the SAML 1.1 security token. Figure 7: SAML 1.1 token generation Testing the Integration When the WCF test program is invoked, a the RST message sent from the WCF client to the TFIM STS can be collected using TFIM trace. A sample is shown in the listing below. http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue urn:uuid:9f0a33e2-b254-45b8-ae1f-baf888635b18 2ed4b1cb-6e50-460a-b4aa-c10af2ccc9f5 http://www.w3.org/2005/08/addressing/anonymous https://tam60:9443/TrustServerWST13/services/RequestSecurityToken 2009-07-23T21:02:00.046Z 2009-07-23T21:07:00.046Z testuser o:Password> http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue https://tam60:9443/SampleService/Service1.svc JKsRMe/kSQoId91r1se1FnEwmi9mnH1exRBkPf7tOK0= http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile- 1.1#SAMLV1.1 http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey 256 urn:wcf Notice the UsernameToken in the SOAP header (the password is grayed out by TFIM trace). Notice the relationship between the AppliesTo, Issuer and TokenType in the RST within the SOAP body, and the corresponding settings in the WCF client application configuration. The Entropy, KeyType and KeySize are ignored by the TFIM STS. Also using TFIM trace, the response from the TFIM STS can be captured. A sample is shown in the listing below. http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal urn:uuid:9f0a33e2-b254-45b8-ae1f-baf888635b18 urn:uuid:9f0a33e2-b254-45b8-ae1f-baf888635b18 http://www.w3.org/2005/08/addressing/anonymous http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile- 1.1#SAMLV1.1 https://tam60:9443/SampleService/Service1.svc 2009-07-23T21:02:00Z 2009-07-23T21:03:00Z https://tam60:9443/SampleService/Service1.svc testuser Assertion-uuida96ba724-0122-168a-a8fc-f069c9a67f9f Notice that the response is a RequestSecurityTokenResponseCollection message. This is standard behavior for TFIM's WS-Trust 1.3 endpoint. The SAML 1.1 security token is shown. Notice that the Subject element contains the same username sent in the RST. If more complex identity mapping was performed in TFIM, this could be a different identity, such as the user's email address or other unique identifier. Troubleshooting TFIM Troubleshooting Visibility into the internal processing of the TFIM STS can be achieved by enabling WebSphere Application Server trace in the instance(s) running the TFIM Runtime. The trace configuration should include: com.tivoli.am.fim.trustserver.*=finest WCF Troubleshooting Steve Moseley's article on "Tracing SOAP Messages in WCF" provides simple, effective instructions on configuration detailed WCF trace. Enabling this trace is helpful as it shows more detailed information, messages and exceptions compared to what will be seen from catching and displaying error messages from the WCF application itself. The listing below shows the WCF trace configuration used in this scenario. The information obtained during from this trace proved to be useful in debugging errors and adjusting configuration settings. It is expected to be equally useful when exploring similar scenarios or those that extend the one documented here. . . . . . . . . ? Future Work This article describes one interoperability scenario for TFIM STS and Microsoft WCF. Different environments are likely to dictate slightly different requirements. Some obvious extensions to the scenario in this article are: Return a signed SAML 1.1 security token from the TFIM STS to WCF Send the user's identity in a different form to the TFIM STS, e.g. Kerberos token. This could include a scenario where the TFIM STS is used from an ASP.NET application where the user's password is not available and the ASP.NET application needs to get a security token on behalf of a user. Return a different type of security token from the TFIM STS, e.g. SAML 2.0. Note: SAML 2.0 is a token type for which WCF does not provide any native support and the integration technique is more complicated. It may be more appropriate to consider this use case with Microsoft Geneva instead of WCF. Service provider pattern. This approach is generally considered less desirable that the service requester pattern, but may be applicable in some cases. Conclusion WS-Trust is a standard that allows security tokens to be validated and exchanged in a trusted way. This enables user identities to flow from component to component in heterogeneous web services and SOA environments. This article has demonstrated an interoperability profile that allows Microsoft Windows Communication Foundation to access the Security Token Service in Tivoli Federated Identity Manager using WS-Trust to obtain a SAML 1.1 security token for inclusion in a web service request.
  • 下载地址 (推荐使用迅雷下载地址,速度快,支持断点续传)
  • 免费下载 PDF格式下载
  • 您可能感兴趣的
  • www.a67.com  www.a67.com.cn  www.a67.cn  www.a67.net  www.rijialu0.com  www.0dian8.com  www.line0.com  www.equlu0.com  www.88x0x0.com  www.99v0v0.com