{"id":1020,"date":"2008-11-01T10:02:57","date_gmt":"2008-11-01T18:02:57","guid":{"rendered":"\/?p=1020"},"modified":"2008-11-01T23:22:32","modified_gmt":"2008-11-02T07:22:32","slug":"project-geneva-part-2","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=1020","title":{"rendered":"Project Geneva – Part 2"},"content":{"rendered":"

[This is the second installment of a presentation I gave to Microsoft developers at the Professional Developers Conference (PDC 2008) <\/a>in Los Angeles. It starts here<\/a>.]<\/em><\/p>\n

I don\u2019t want to overwhelm you with a shopping list of all the scenarios in which the Claims-based\u00a0architecture solves problems that used to be insurmountable.<\/p>\n

But I\u2019ll start from the enterprise point of view, and look at how this system helps with the big new trend of federation between partners. Then we\u2019ll look at cloud computing, and see that the same architecture dramatically simplifies developing applications that can take advantage of it. \u00a0Finally, we\u2019ll see how the\u00a0approach applies to consumer-oriented web applications.\u00a0\u00a0<\/p>\n

\"\"<\/p>\n

Enterprise Federation<\/strong><\/p>\n

The rigid Enterprise perimeter is dissolving as a result of\u00a0the need for\u00a0digital relationships between an enterprise and its suppliers and customers, as well as the outsourcing of functions and services, the use of temporary workers, and having employees who sometimes work from home.\u00a0 The firewall is still a useful element in a\u00a0concentric set\u00a0of defences, but must at the same time now be permeable.\u00a0<\/p>\n

Most of us are\u00a0even\u00a0learning to collaborate on a per-project basis with partners who in other contexts might be our competitors.\u00a0 So the relationships between business entities must be defined with more and more granularity.<\/p>\n

In looking at this,\u00a0I\u2019m going to start with a very simple scenario – a story of two companies, where one has built an app in-house or has installed an ISV app for their own employees, and now\u00a0wants to extend access to employees from a partner.<\/p>\n

In the past, even this simple requirement has been really hard and expensive to fulfill. How can Microsoft help you solve this problem using the claims model?<\/p>\n

Code name Geneva<\/strong><\/p>\n

Well, I'm happy to announce today, the first beta of \u201cGeneva\u201d software for building the claims-aware applications I\u2019ve been talking about. It has three parts:<\/p>\n

    \n
  1. \"\"The \u201cGeneva\u201d Framework: A framework you use in your .Net application for handling claims. This was formerly called \u201cZermatt\u201d.<\/li>\n
  2. \u201cGeneva\u201d Server: A claims provider and transformer (STS) integrated with Active Directory.\u00a0 It\u00a0comes with Windows, and makes managing trusts and policies easy.\u00a0 Importantly, it supports Information Cards, making it easier for people to understand what identities they are using where, and to avoid phishing of their enterprise credentials<\/em>.\u00a0You may in the past heard this\u00a0server being\u00a0referred to as\u00a0AD FS \u201c2\u201d.<\/li>\n
  3. Windows CardSpace \u201cGeneva\u201d:\u00a0 The second generation Information Card client for federation that\u00a0is dramatically faster and smaller than\u00a0the first version of CardSpace,\u00a0and incorporates the feedback and ideas that have emerged from our customers and collaborators.<\/li>\n<\/ol>\n

    In the use case we\u2019ve been considering, our solution works this way:\u00a0 each enterprise puts up a single Geneva Server \u2013 leveraging the power of their Active Directory.<\/p>\n

    Then the\u00a0administrators of the application\u00a0alter\u00a0the .NET configuration to point to\u00a0their enterprise\u2019s Geneva server (with the config change I demonstrated here<\/a>\u00a0). At this point, your customer's application has become part of what we call an\u00a0Enterprise identity backbone, and can accept claims.<\/p>\n

    So the\u00a0software\u00a0framework and components provide a\u00a0single identity model that users configure in any way they want.\u00a0 If you have\u00a0written to this model, your app now works for both \u201cemployees\u201d and \u201cpartner users\u201d without a code change. All that is required is to set up the Geneve STS\u2019s .<\/p>\n

    The fatal flaw<\/strong><\/p>\n

    \"\"Anyone who has been around the block a few times knows there is one fatal flaw in the solution I\u2019ve just described.<\/p>\n

    Your customer may have partners who don\u2019t use Active Directory or don\u2019t use Geneva or have settled on a non-Microsoft product.<\/p>\n

    No problem.\u00a0 All aspects of Project Geneva are based on standards accepted across the industry \u2013 WS-Trust and\u00a0WS-Federation.<\/p>\n

    I\u2019m also very happy to announce that Geneva supports the SAML 2.0 protocol. Basically, no system that supports federation should be out of reach.<\/em><\/p>\n

    All this means your partners aren\u2019t forced to use \u201cGeneva\u201d if they want to get access to your applications. They can use any third party STS, and that is part of the great power of the solution.<\/p>\n

    Does Microsoft practice what it preaches?<\/strong><\/p>\n

    Microsoft is an enterprise too.\u00a0 So if this architecture is supposed to be good for our enterprise customers, what about for Microsoft itself?\u00a0 Are we following our own advice?<\/p>\n

    \"\"I\u2019m here today to tell you Microsoft has fully stepped up to the plate around federation. And it is already providing a lot of benefits and solving problems.<\/p>\n

    You've heard a lot at the PDC about Azure<\/a>. Microsoft offers cloud applications like hosted SharePoint and Exchange, and cloud developer services like the .Net Services and SQL Data Services, as well as\u00a0a whole range of applications.\u00a0 We want other enterprises to be able to access these services and sites, much like other enterprises want their own customers and partners to access the systems pertaining to their businesses.<\/p>\n

    So we make\u00a0our offerings\u00a0available to customers via the\u00a0Microsoft Federation Gateway (MFG), which anchors our \u201cservices identity backbone\u201d, and is based on the same industry standards and architecture delievered through the Geneva Project's server. It is all part of one wave, the Geneva wave of Identity Software\u00a0+ Services.<\/p>\n

    The result is pretty stunning, in terms of simplifying our own lives and allowing us to move forward very quickly – as it will be for enterprises that follow the same route. Through a single trust relationship to our gateway, our customers can get access to our full range of services.<\/p>\n

    Again, we\u2019re not telling our customers what federation software to use. They can federate with the MFG using \u201cGeneva\u201d or other third party servers that support standard protocols.\u00a0 And they can use the same protocols to federate with other gateways run by other organizations.<\/p>\n

    What about Live ID?<\/strong><\/p>\n

    It is important to understand that the Microsoft Federation Gateway is different from Windows Live ID.\u00a0 Yet Live ID feeds into the Gateway just as all our partners do.\u00a0 I'll describe this, and the cool implications for application develoeprs of this approach,\u00a0in the next installment.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Solving problems with Claims<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[37,43,10,2,8,15,42],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1020"}],"collection":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/users\/68"}],"replies":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1020"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/1020\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1020"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1020"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1020"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}