Using SQL Attribute Store with Active Directory Federation Services 2.0 (aka Geneva Server)

Active Directory Federation Services 2.0, also known as Geneva Server, can act as a Security Token Service (STS) for a claims-aware application (called Relying Party in this context) by providing a security token containing the claims demanded by the application.
To produce the claims, ADFS 2.0 uses the Active Directory as attribute store and retrieves attributes about identity of the authenticating client.

You can imagine cases where all the information needed to build the claims cannot be found in the Active Directory.

An application might for example request an age verification of the caller. This can be done by letting the STS retrieve the birthday of caller from an external database and producing a producing a ‘AdultVerification’ claim containing true or false.

Step by Step implementation

1. Define the external attribute store in the Geneva Server

The external attribute store is a SQL database containing a table BDates. Since we are using integrated security and the database is accessed by the Geneva service, do not forget to configure access for the service account (Network Service in this case)

2. Define a new claim type for the AdultVerification claim

3. Add a custom rule to the relying party to construct the AdultVerification claim

4. Specify the expected claims in the web.config of the relying party

At this point you can access the AdultVerfication claim in the application code and implement access checks as shown in the following code sample.
A better and more flexible way is to write a custom claims authorization manager module so that you can configure the access in the configuration file of the application.

5. Write a custom claims authorization manager

6. Configure the application to protect pages

Add the ClaimsAuthorization module to the http modules of system.web and system.webserver

Configure the custom authorization manager to protect the SecretPage.aspx

Test the application. When an underage user navigates to the SecretPage, following error is returned

In a next post I will describe how to build a custom attribute provider, so that external attributes can be retrieved using any custom mechanism (for example via a web service).

Using message credentials when calling a SOAP service from Silverlight 4

Silverlight 4 beta introduces the possibility to pass user credential (username/password) to SOAP services via the request headers. This is important when you enable a SOAP service for crossdomain access.

Shortly summarized, this is how it works:

1. Add an https binding to the service and configure this binding to use transport security with message credentials.
2. Use SLsvcutil.exe to generate the SL proxy.
3. Add the username and password to the ClientCredentials.UserName property of the proxy.
4. Remember to allow https request headers in the crossdomain policy file.

Example:

The question arises if this way of working is safe enough in true business environments.
When we look at a network trace we can notice that the username/password information is protected because of we are using https. When we enable the WCF message tracing on the server, we see that the values of the username and password have been silently removed from the trace.

To see what is really in the headers of the SOAP message, I added a message inspector to the WCF service. This inspector logs the content of the headers to a trace file. This is the content of the trace file:

Notice that the values for the username and the password are visible in plain text.
The problem is that anyone (with bad intentions) who has access to the configuration file of the service can add such an inspector to the service.
This combined with the fact that server credentials are negociated via the transport protocol (https), you can find yourself in a possible unsafe situation.

Using full WS bindings with username/password is a whole different story. In this case the server must present a well known certificate that is specified in the client configuration. This way you are sure to be talking to the right party. Secondly the username/password is encrypted and can only be decrypted by the receiving service.
The same message inspection on a full WS service gives following trace file:

Conclusion: Although you can use username/password authentication to SOAP services in SL4, be aware that it uses TransportWithMessageCredentials under the covers and that the username/password information is not encrypted at message level. This opens possibilities for "man in the middle" and "phishing" attacts to reveal usernames and passwords.