Wednesday, December 30, 2009

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

Noname3

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)

Noname4

2. Define a new claim type for the AdultVerification claim

Noname7

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

Noname11

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

Noname15

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.

Noname22

5. Write a custom claims authorization manager

Noname26

6. Configure the application to protect pages

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

Noname32

Noname34

Configure the custom authorization manager to protect the SecretPage.aspx

Noname38

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

Noname44

Noname48

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).

Monday, December 14, 2009

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.

Saturday, October 24, 2009

Windows and .NET Idenity and Security "Back to basics" series. Part 1.

Motivation

I decided to start writing a series of articles on the identity and security mechanisms in .NET and Windows. This idea grew while talking to my -almost all of time younger- colleagues about .NET security. I started realizing that for developers who only worked in .NET environments, it is not that easy and obvious to understand how some of the .NET functionalities such as for example authentication and threading relate to the basic Windows operating system subsystems.

When developing in the .NET ecosystem we all are aware of the existence of sets of rules (or laws) that exist and that have to be respected. Examples of these laws and regulations in the .NET world are Code Access Security (CAS), Role-Based  Security, AppDomain rules and many others. So when writing .NET code you have to play by the rules of the .NET world. But in the end when the .NET application is executed (and we all hope it eventually will) by the Windows operating system, a whole different set of rules apply. The reason is that the operating system treats the .NET application just like any other application or process on the machine, and here the game is played by the rules of the operating system. And since we all know that operating systems are a lot like the Old Testament gods (a lot of rules and no mercy), things can go wrong.

In a nutshell, in this series of articles I will try to explain the rules regarding identity and security in the .NET world and how they relate and map the corresponding rules in the Windows operating system world.
I will try to follow Albert Einstein's advice - keep this as simple as possible, but not simpler - and that is why this series is called "Back to basic".




Identity in the Windows world

When the operating system wants to protect access to its resources (files, communication ports, shared memory, semaphores and others) it needs to identify who is requesting access to the resource. It is clear that the process of identifying who requests access must provide strong authentication. When it is easy to fake another identity, there would be no security!

The Windows operating system grants or denies access to a resource based on an access control list (ACL). The ACL is a list of elements (ACE's) describing who can or cannot be allowed a certain type of access (Read, Write, Update or other) to the resource in question. Each ACE describes an access type for a Security Principal.

A Security Principal is an abstract term to indicate the party whishing to access the resource. Examples of Security Principal are users, machines, user groups.

A Security Principal is identified by a security identifier (SID). A SID is a structure that is unique in time and space that is issued by a trusted authority. For example, a SID representing a local user on a Windows machine is issued by the local security authority (LSA) component on the machine, while a SID representing a domain account is issued by the domain's security authority.

I won't go into details describing the format of SID's, but it is important to notice that besides the SID's issued by the authorities to identify user defined parties (such as individual users), there is a category of Well Known SID's that exist in every installation and always have the same value. Examples of Well Known SID's are the EveryOne user group, the Creator/Owner and the Administrator SID.

In the next figure the PsGetSid utility from http://www.sysinternals.com/ is used to display the SID of Everyone (Well Known SID), a local user and the machine.




Following figure shows the detail ACL for a file name MyFile.txt after the security was configured using the standard Windows explorer.

 

This concludes the introduction. Remember that there is a lot more to tell about SID's and ACL's (for example how inheritence works), but this should be sufficient to understand the relation with the .NET world later.
In the next part we will talk about processes, threads, process tokens and how they relate to security identifiers. After that we will have set the scene to dive into the .NET world.

Sunday, October 18, 2009

Using enums with NetDataContractSerializer

When using the NetDataContractSerializer in WCF you can run into troubles when serializing enum types. If you do not specify a zero value for the enum, and try to serialize/deserialize a collection (such as an IList) of enums, you will get a serialization exception stating that no '0' value for the enum was defined. Example: public enum ColorsNonZeroBased { Red = 1, Orange = 2, Green = 5 } When trying to serialize IList you get the following exception: System.Runtime.Serialization.SerializationException: Enum value '0' is invalid for type 'Bromo.TaskChannel.Test.ColorsNonZeroBased' and cannot be serialized. Ensure that the necessary enum values are present and are marked with EnumMemberAttribute attribute if the type has DataContractAttribute attribute.. The solution is to provide a zero value for the enum (which is probably the recommended solution), or you can add a [FlagsAttribute] to the enum.