After a short but sweet weekend, we are back to our federation chat. Last week I presented the perspective of the application (RP) developer who, while not being an identity guru, does take advantage of identity info for driving the behavior of his application. Today we are going to see things from the perspective of the administrator who runs the IP (which in our sample is called Adatum) and makes possible the claims flow from the IP to the RP.

Let’s see a quick itemized summary of the steps that the developer performed during the last installment:

1. created the application website
2. Used fedutil for establishing a relationship with the IP (Adatum)
1. Entered the apps’ coordinates (web.config & URI)
2. Pointed to the IP metadata
3. Cherry-picked the claims the application requires
4. Wrote down the URI of the newly created application metadata
3. Sent the URI of the application metadata to the IP and waited for an answer
4. Received the green light from the IP and completed the application with code that takes advantage of identity info

What we describe today takes place between the step 3 and 4 above.

Establishing a Relationship with a Relying Party

Today we are an administrator at Adatum. We just received an email from our partner, FabrikamShipping, informing us that they provisioned an app that relies on claims coming from Adatum and they need us to register it in our systems, so that the claim juices can start to flow. They provide us with the URI of the application metadata, a piece of data that makes our job really simple.

We start by firing up the Geneva Server MMC.

As you may have guessed from the names, this Geneva Server is the same one I used for the demo in Kim’s PDC session: the RPs listed above are the ones with which Adatum already has a relationship, namely the Microsoft Federation Gateway (used for SSO in CRM online in the demo), the fabrikamshipping shipping application (the main demo app) and a little experiment from the geneva framework sample list. For details about the scenario in which those are used, please refer to the demo parts of the session above (minute 31’ on in this video).

Let’s go ahead and add a new relying party: in line with the MMC experience, we can easily do that via action pane or via right-click:

And in good tradition, the process is implemented in wizard form.

The very first step is retrieving the application’s metadata, so that we can get to know all the requirements at once & unambiguously; even better, we can count on this for tracking the future evolutions of the app and maintain the relationship accordingly without having to corral many different scattered parameters. Now THAT’s progress!

Note that the UI also allows us to address the case in which we don’t have metadata available and we want to enter parameters manually: that would be the case for the Access Control Service, for example.

The system verifies that the metadata document is there and valid, then moves on. Here we can add some mnemonics for the RP entry in our UI.

The next step is interesting, because it shows the benefits of metadata use in action. Here we can see the claims that the RP requires, as they selected it from the list we made available in OUR metadata. In the generic case, however, it may happen that they would be asking fro claims we don’t issue (yet), or we may have reasons for refusing to issue a certain claim to this relying party; in any case, Geneva Server gives us full control on the set of claims that your IP will issue.

In this case, we keep everything that the RP asks for. Later we’ll see that there’s a  little catch for “Phone”.

Here we are. The wizard gathered all the info it needed for creating the relationship, and shows us a summary page which presents the info about this RP in the same UI that will be used in the MMC for the same purpose.

We are satisfied and we move to the next step; that adds the RP to our policy store. We are in an official relationship now, and so much for my fears of commitment 🙂

Here there’s our new default view: as you notice, we have a new entry.

Actually, in this specific case we are not 100% done yet. The RP asked us for 3 claims: Name, Group and Phone. Name is a built-in claim type, and its value is automatically sourced from AD. Group is a claim we added ourselves, hence we provided manual sourcing to an AD attribute. Phone is again an arbitrary claim type we added, however we didn’t yet specify how Geneva Server should assign a value to it when it is required to issue a Phone claim. Luckily, adding this information is really really easy. Let’s select right-click->properties on our RP. We get to the dialog below.

If we pick the tab “Claims”, we’ll see 4 entries in there:

• One Group entry for the Identity Provider. That means that Group is a claim that our IP exposes
• One Group entry for the Attribute Store. This entry contains a rule which tells to Geneva Server which value should be assigned when a Group claim is requested
• One Name entry for the Identity Provider. That means that out IP exposes the Name claim. We don’t need further rules, as this is a built in claim
• One Phone entry for the Identity Provider. That means that Phone is a claim that our IP exposes. However this is not a built in claim, hence we need to add a corresponding Attribute Store rule for sourcing Phone correctly. Let’s click “Add Rule”

We pick Attribute Store; note that there are other interesting options in there, including using other claims as sourcing

Grabbing the value is TRIVIAL: you just write down the LDAP attribute name you want to assign. If you don’t have the luck of having Donovan handy, the man is a directory encyclopedia, you can always install some utils like AD Explorer. In our case, the magic word is telephoneNumber.

And we’re done. A quick double check of the summary, and we are good to go.

Now our issuance rules list is complete.

Our RP is all set: we can notify the devs at FabrikamShipping that they are now cleared for receiving tokens from Adatum, in the format requested and with the set of claims they need.

Here our administrators did have to know what a claim is, but it was still astonishingly simple to set this up: as you may have noticed I didn’t see a single mention of X509 certs or long list of arcane addresses, the only thing i needed was the application metadata URI and everything went downhill from there. In fact, I was able to go through this even if I am very far from being an expert in Geneva Server (for that you need to go to the Geneva team blog, the forum or Donovan’s blog) 

Great! This concludes our little excursus in federation, hope you had fun. But I’m not not done with WS-Federation just yet: expect still some posts about it 😉