Sentinet – Service Virtualization Part 6 - BizTalk Server

In the previous post I have demonstrated how I can secure my internal BizTalk services application with X.509 certificates security (that might represent a hypothetical B2B application-to-application scenario). For that, I did not have to change anything in the way my internal BizTalk application is deployed or configured. I accomplished that by simply virtualizing the BizTalk service through a Sentinet virtual endpoint that requires X.509 certificate. I also showed how Sentinet provides additional managed access control (authorization) and messages exchange monitoring.

In this post I would like to continue, where I left off in the previous post, and demonstrate how to set up my virtual service with yet another endpoint that will enable my BizTalk application with a different security mechanism based on SAML claims. I will use a SAML token to demonstrate a Federated Security scenario. Effectively, the objective of this use case will be to enable my BizTalk service to be a “claims-aware” application with no coding or any changes in how my existing BizTalk application is deployed and configured. See the diagram below that shows my objective in this post.



The flow of interaction is as follows:

1. Client application provides user credentials (username/password in my sample setup), to the external Security Token Service, the Windows Azure Access Control Service (ACS) in my sample setup (it can also be an on-premises Microsoft ADFS service).
2. The Windows Azure ACS maps provided client credentials to a set of business claims, and issues a SAML token for the client application.
3. The client application sends a request message with attached issued SAML security token.
4. A virtual service hosted in the Sentinet Node validates the SAML token and processes the SAML claim(s) to provide authorization based of the claim(s) and their value(s).
5. The virtual service forwards the request message to the BizTalk service using internal security (for example using Windows integrated internal security).

The setup of the virtual service endpoint and the security configuration consists of the following steps, which I will cover in more details later in this post:

• Setup a trust relationship between Sentinet Node and Windows Azure ACS. This step will configure Sentinet Node with the Windows Azure ACS specific instance as an issuer of SAML tokens that will be trusted by the Sentinet Node.
• Configure a Security Token Service (Windows Azure ACS in our sample) with:
• Username/password mappings to custom SAML claim(s).
• Sentinet virtual service as a relying party that receives SAML claims.
• Create the endpoint for the Sentinet virtual service.
• Configure the endpoint with the security policy that requires a SAML token.
• Assign Access Rule and Access Control to the endpoint (assign authorization rules). Access Rule will require a business claim issued by the specific claims issuer and with specific claim values.
• Write a test client to access the virtual service endpoint.

The first step is to configure Sentinet Node with the Windows Azure ACS instance as a trusted issuer of the security tokens. STS Server (Windows Azure ACS in this case) issues SAML tokens signed by its own Issuer Identity. By default, this is an X.509 digital certificate of an STS itself, and that certificate is the actual Issuer Identity that has to be configured with the Sentinet Node as an identity of a Trusted Issuer. Therefore we have to add a Trusted Named Issuer to the Sentinet Node (SteefNode in my case). Navigate to the Sentinet Node properties, click the Modify toolbar button and subsequently the Add Identity button located next to the Trusted Named Issuers list.



In the Add Trusted Issuer Identity dialog box we specify an Issuer friendly name, select the X.509 certificate thumbprint choice and choose Next.



The Windows Azure ACS signing certificate’s thumbprint can be retrieved from the Microsoft ACS portal in Windows Azure. We enter that thumbprint in the Sentinet dialog box and click Finish. We have now configured the Sentinet Node with the specific instance of the Windows Azure ACS as a Trusted Named Issuer of security tokens. Any virtual service hosted in that Sentinet Node may now be further configured with a specific Access Rules to accept tokens issued by the ACS. Note, that Sentinet Node may be configured with more than one STS Server as a trusted issuer, which makes it possible to host virtual services that require different token issuers.



The next step is to configure the ACS itself to issue security tokens. We will configure the ACS to issue a custom SAML claim about the user when a user presents to ACS his username and password. Note that there are other means of issuing security tokens by ACS, besides those that are based on the username and password credentials.

The following sequence of steps describes the setup of the ACS to issue claims based on the username/password credentials:

• Add Service Identities.

A service identity is a credential that is registered with an Access Control namespace and is intended for use by autonomous applications or clients (username/password credentials in our case). In other words, service identities are credentials that are configured globally for the Access Control namespace that allow applications or clients to authenticate directly with ACS and receive a token. An Access Control namespace may contain many service identities.

• Create Rule group.

A rule group is a named set of claim rules that define which identity claims are passed from identity providers to your relying party application. In ACS, rule groups are associated with relying party applications, where in our case relying party application is the virtual service hosted in the Sentinet Node.

• Add Rule to Rule group.

Rules describe the logic of how ACS transforms input claims into output claims. Rules are contained within rule groups, which are associated with relying party applications and are run through whenever a token is issued by ACS for an application.

• Add Sentinet virtual service as a Relying party application.

Relying party applications are your services for which you want to use ACS to implement federated authentication. Relying party applications consume claims from identity providers to make authentication and authorization decisions.

First you need to log into the ACS portal in Windows Azure. Under the Service settings section in the left pane we select Service identities. Here we need to setup the identity of the service that will be configured with a username/password credentials for authentication with ACS in exchange for a security token. In Service Identities we click Add and specify a name (example: UserTest). Subsequently in this page we also click Add to create a specific username/password credential for authentication of our client.



In the next step we will select Rule groups under the Trust relationships in the left pane. In the Rule Groups we select Add, specify a rule group name and click Save. Subsequently, we click the newly created rule group and edit the rule group by adding a new rule. We click Add and Add Claim Rule page will appear. In this page we specify few properties like Input Claim Issuer, Claim Type, and Input Claim Value. Beside input, we also specify the Output Claim Type and Value, and optional Rule Information. Effectively this page is where we configure ACS with the actual mapping between the original username/password credentials (Input Claim) and an Output Claim (which is what will be a custom SAML claim of type http://steefjan.com/running/racename with the value of Berlin Marathon 2014).



Our client application will authenticate directly with ACS, therefore we choose ACS as our Identity Provider. We select a standard nameidentifier as input claim type with the Input claim value UserTest, which is the name of the Service Identity that we created earlier. Note that there is no password credential on this page because it is being configured behind the Service Identity itself. The output claim type will be a custom URI, http://steefjan.com/running/racename. The claim value will be Berlin Marathon 2014. Think of a business service that only needs to know the business specific claims about the user (thus it is a “claims-aware” application), and does not care about the original user identities. This is where we just configured ACS with these business-centric claims and the ACS’s responsibility to issue these claims as long as the ACS can authenticate user based on his username/password credentials. When we specified all the required fields and values we click Save.

The final step in ACS is to create a relying party application, which is the Sentinet virtual service that will receive claims issued by ACS. Under the Trust relationships we select Relying party applications. Next we click Add to create a relying party application.



We specify the Name, Realm, Token format and Token encryption policy. Next we specify the authentication setting, which is the previously created Rule group and specify a certificate for encryption of the Token. Issued SAML token will be signed by the ACS certificate (which was previously configured with the Sentinet Node as an identity of a Trusted Name Issuer), but the SAML token will also be encrypted using recipient’s public certificate (which is the public certificate of the Sentinet Node that receives SAML tokens). We upload the Sentinet Node’s public certificate to the ACS portal as a Token Encryption Certificate configured with the relying party. Note that Sentinet console provides a link to download the Sentinet Node public certificate from the Node Summary screen.



We have now specified all the required settings for the relying party application:



Our next step in this sample is to setup an endpoint in our virtual service that is configured with security that requires SAML token. We will use the Sentinet console to create a new virtual endpoint that is configured with the following binding:




The binding itself actually defines two bindings, where one of them references another. The “outer” binding is for the virtual service endpoint itself, while the “inner” binding is for the client application to request SAML token from the ACS. Note that as far as the virtual service concerned, it only needs the outer binding, so that the inner binding does play any role in the virtual service runtime. But remember that Sentinet is also a design-time governance tool and a generic SOA Repository. As such, it plays many roles and among its benefits it gives client applications easy access to all information (specifically service metadata) that clients have to know about the service. In this case not only Sentinet Repository configures virtual service with the proper security, but it also gives clients a “hint” on how to talk to the external STS server.

Therefore the first binding named IssuedToken specifies that the virtual service has to be configured with the requirement to expect SAML claim (authenticationMode property). It also provides address with the additional information (metadata) of the issuer of the SAML Token, and the address of the issuer service endpoint with the reference to that endpoint’s binding. The issuer address tells the client where to go to receive the SAML token from ACS. The second binding named AcsBinding tells the client how to communicate with the ACS through this endpoint, specifically that the client has to provide username/password credentials. Basically the binding contains the requirements for the client to talk to ACS.



Now that we have created the endpoint we need to assign an access rule to the endpoint. Although we have configured the endpoint with the SAML token requirement, we have not specified which specific claim is expected from the client application. Without the specific access rule Sentinet will only check validity and the trust of the SAML token, which would be typical for any default configuration of a claims-aware WCF service. Academically speaking, SAML token validation is all about caller authentication. As I was writing in all my previous posts about Sentinet, it also provides remote configuration and management of the access rules (thus Sentinet adds authorization on top of authentication). We will add authorization by assigning a claim based access rule to the virtual service endpoint.

We go to the Access Rules in Sentinet and click Add. Next we specify a name for the rule and drag and drop a Claim expression. We specify the Claim Type, Value and Issuer.



For the Claim Type and Claim Value we enter those specific values that we previously configured ACS mapping with. The Claim Issuer is the name of the Trusted Named Issuer we setup earlier for the Sentinet Node. Last step here is to apply the created access rule to the SAML virtual endpoint. We return to the virtual service and select the Access Control tab, click the Modify button and drag and drop the access rule on the desired endpoint. The endpoint is now secured with the access rule that requires very specific claim for authorization.

Our final step in the sample is to test the endpoint. We will write a simple test client (console app) to access the service endpoint. In Visual Studio we create a new console application, set a service reference to the virtual service with the newly created endpoint. Note the immediate benefit for developers of using Sentinet Repository here. When we build the client application in Visual Studio we select Add Service Reference and provide virtual service’s WSDL URL from the Sentinet Repository. Sentinet virtual service was configured with the binding that has everything in it. All we have to write is the actual code to call the service, while all configurations for our test client will be automatically generated off the Sentinet Repository.

The code in our client looks like below:



Below is the auto-generated binding in the app.config:



When we run the client it will authenticate with ACS first to get the SAML token before it can call the virtual endpoint. We will see how the call to the virtual endpoint is made through the monitoring feature of the Sentinet. In Sentinet Administration Console you can examine this call from the Monitoring screen with all the tracking details, where you can see messages coming in and out of the virtual service.



In the Consumer Identity section you can see the exact claims received and recorded by the Sentinet virtual service. You can see the claim type that we configured with ACS claims mapping, and the claim value of Berlin Marathon 2014. This was also configured as the expected claim type and claim value in the Sentinet Access Rule that we set on our virtual endpoint. If we change claim value in the Sentinet access rule and run out test client again, we will see an access denied SOAP fault generated by the virtual service (which demonstrates how Sentinet provides authorization based on specific claims and their values).



In this post I have discussed and demonstrated a new virtual endpoint that required a SAML token (Federated Security scenario). Effectively, the objective of this use case was to enable my BizTalk service to be a “claims-aware” application with no coding or any changes in how my existing BizTalk application is deployed and configured. BizTalk application was also extended with remotely managed authorization and service calls monitoring. At the same time, as a developer of a client application, I leveraged Sentinet Repository and Visual Studio to quickly build my test client application with the minimum effort.

In the next post I will discuss and demonstrate another interesting use case where I will add yet another endpoint to the virtual service. New virtual endpoint will expose my BizTalk server application to the outside world through the Windows Azure Service Bus. Note, that just like in all other cases discussed in all parts of this blog series, I will not change a thing in my BizTalk application to get this external exposure.

Cheers,

Steef-Jan