{"id":413,"date":"2009-03-23T13:44:00","date_gmt":"2009-03-23T22:44:00","guid":{"rendered":"http:\/\/www.cloudidentity.com\/blog\/2009\/03\/23\/fun-with-federation-2-using-geneva-server-for-adding-a-relying-party-relationship-to-the-identity-provider\/"},"modified":"2009-03-23T13:44:00","modified_gmt":"2009-03-23T22:44:00","slug":"fun-with-federation-2-using-geneva-server-for-adding-a-relying-party-relationship-to-the-identity-provider","status":"publish","type":"post","link":"https:\/\/www.cloudidentity.com\/blog\/2009\/03\/23\/fun-with-federation-2-using-geneva-server-for-adding-a-relying-party-relationship-to-the-identity-provider\/","title":{"rendered":"Fun with Federation 2: using Geneva Server for adding a Relying Party relationship to the Identity Provider"},"content":{"rendered":"
digg_url = “http:\/\/blogs.msdn.com\/vbertocci\/archive\/2009\/03\/23\/fun-with-federation-2-using-geneva-server-for-adding-a-relying-party-relationship-to-the-identity-provider.aspx”;digg_title = “Fun with Federation 2: using Geneva Server for adding a Relying Party relationship to the Identity Provider”;digg_bgcolor = “#FFFFFF”;digg_skin = “normal”;digg_url = undefined;digg_title = undefined;digg_bgcolor = undefined;digg_skin = undefined;<\/div>\n

After a short but sweet weekend, we are back to our federation chat<\/a>. Last week<\/a> 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.<\/p>\n

Let\u2019s see a quick itemized summary of the steps that the developer performed during the last installment<\/a>:<\/p>\n

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

      What we describe today takes place between the step 3 and 4 above.<\/p>\n

      Establishing a Relationship with a Relying Party<\/h1>\n

      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.<\/p>\n

      We start by firing up the Geneva Server MMC.<\/p>\n

      \"image\" <\/p>\n

      As you may have guessed from the names, this Geneva Server is the same one I used for the demo in Kim\u2019s PDC session<\/a>: 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\u2019 on in this video<\/a>).<\/p>\n

      Let\u2019s 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:<\/p>\n

      \"image\" <\/p>\n

      And in good tradition, the process is implemented in wizard form.<\/p>\n

      \"image\" <\/p>\n

      The very first step is retrieving the application\u2019s 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\u2019s progress!<\/p>\n

      Note that the UI also allows us to address the case in which we don\u2019t have metadata available and we want to enter parameters manually: that would be the case for the Access Control Service, for example.<\/p>\n

      \"image\" <\/p>\n

      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.<\/p>\n

      \"image\" <\/p>\n

      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\u2019t 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.<\/p>\n

      In this case, we keep everything that the RP asks for. Later we\u2019ll see that there\u2019s a  little catch for \u201cPhone\u201d.<\/p>\n

      \"image\" <\/p>\n

      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.<\/p>\n

      \"image\" <\/p>\n

      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 \ud83d\ude42<\/p>\n

      \"image\" <\/p>\n

      Here there\u2019s our new default view: as you notice, we have a new entry.<\/p>\n

      \"image\" <\/p>\n

      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\u2019t 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\u2019s select right-click->properties on our RP. We get to the dialog below.<\/p>\n

      \"image\" <\/p>\n

      If we pick the tab \u201cClaims\u201d, we\u2019ll see 4 entries in there:<\/p>\n