4.1 Creating claims identity

Let's update our model and add some code that would allow us to construct a claims identity for a user. We will start by declaring a type for email in the email_address.xom file, which we're planning to use as the user ID. We will also use this type on the email field of the "email address" object.

Next, we will create an enumeration "person type" with possible values of the person type and their descriptions, as well as declare a type with the same name for that enumeration, and will use that type on the "person type" field in person.xom.

With that done, let's declare a structure "person info" that will contain all the necessary information for the security claims as follows.

Finally, let's add an operation "read" to the “person” object, which will accept an email address as the input key, and output the “person info” structure that we created. This operation will be used by the authentication logic to create a claims identity, and should not be exposed via REST or WCF APIs, so we need to configure it as such. Given that the structure for this operation is very custom, Xomega will not be able to generate a meaningful default implementation for this method. Instead of trying to inline any custom code into the generated service file like we did before, we will want to just subclass that generated service, and override the entire method in there. To enable that, we will add a svc:customize element to the config section of the “person” object, and will set its subclass attribute to true. The following picture illustrates this setup.

Let's build the model, and navigate to the generated PersonService class under the AdventureWorks.Services.Entities project. Nested inside that class will be a file for the custom service implementation PersonServiceCustomized. Let's go ahead and implement the Read operation there as follows.

As you see, we are using several joins and some rather cumbersome left joins in LINQ to retrieve the data. If we cannot find the person by the provided email address, then we add a critical error with appropriate message, which we added to the Resources.resx, and use the generated constant for the message code.

In order to encapsulate common security related code that can be shared between different types of projects, we will add a new static class called SecurityManager to the AdventureWorks.Services.Common project, where we will define a method that creates claims identity from a PersonInfo structure as follows.

For most of the fields in the PersonInfo structure we used standard claim types. For the person type we used the Role claim type, which is consistent with how we're using it in the first place. For any non-standard info, such as the store ID or the vendor ID for the user, we're using custom claim types, which we declared as constants at the top of the class.

To simplify any security checks in the code, we can also define some handy extension methods on the IPrincipal interface. For example, the following methods will allow us to easily check some user roles, while also leveraging constants that were generated from the "person type" enumeration that we defined in the model.

Here's another example, where we can easily retrieve typed values of the custom claims, such as the store ID associated with the user.

Now that we have done all the prep work for creating a claims identity, we can move on to implementing user authentication.

Next: 4.2 Adding password authentication >