Identity Federation: Lessons From the Trenches<br />Nalneesh Gaur<br />Principal and Chief Security Architect<br />Nalnees...
Our Journey<br />What problem did we solve?<br />How did we do it?<br />What did we learn?<br />What did we do?<br />
Pain and Promise<br /><ul><li>Lengthy Provisioning Process
Repetitive, Redundant, Different
“Slow Trust”
Collaboration / “User” Growth
Cumbersome Authorization
Cost</li></ul>What problem did we solve?<br /><ul><li>Improved User Experience
Faster Secured Collaboration
Fewer IDs
Additional Security Options
Upcoming SlideShare
Loading in...5

Identity Federation for the Enterprise: Lessons Learned


Published on

Talk on Identity Federation: Lessons from the Trenches presented at the EEMA conference, London, June 9th 2010. Zach Sachen and I share our experiences on implementing a full fledged ID Federation solution.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Nalneesh opens w/ self intro, then Zach self intros and covers next slide
  • ZachOur client recently rolled out &lt;we are in the process of doing this for one app/technology - e.g. for an alliance team site; just didn’t want to over state&gt; an Identity Federation(IdF) solution across their enterprise.  While, the (IdF)vision of outsourced Identity Management is real, success requires vision, perseverance, and disciplined execution.  The major steps to realize success include an understanding across four areas: Users, Business Architecture (policy and process), Infrastructure, and Applications.  &lt;include descriptions of each below - see prior decks for the descriptions&gt;Developing an Architecture that align with the Corporate business and Information Security goalsPlanning the role out by carefully selecting and sequencing the applications that lend themselves to federation both inside and outside the enterpriseLaunching a pilot that tests both the technology and process implications of the solutionIn this talk we will share our experiences regarding building momentum, designing, and realizing Federated Identity.  We will use our experience at large organizations (e.g. federal government agency and large pharmaceutical company) as a backdrop.  We expect the audience to be able to apply these insights in their own environments.*** Important to let the audience know that the this talk is not about various protocols and technology standards such as SAML, WS-Federation, Microsoft’s roadmap. We however did leverage experts in our journey and the knowledge is incredibly useful ***
  • Nalneeshtalk about success measures when talking about benefits/promiseImproved ComplianceSafe Harbor, PII, HIPAA, etc.Improved Securitymultiple options from identity providers – e.g. OTP with Blackberry/cell,securID, etc.Improved Collaboration / User Experienceseamless access and authorization in the cloudmore up front, pays dividends in long runBetter User Experiencefaster, less clicks, self-serviceeSignaturesEconomies of ScaleMetcalf’s network law – the more that join the more valuable it will bevolume discounts with providerssupport modelCost Savingsde/provisioning, resets, troubleshootingreused credentials
  • NalneeshDescribe the three scenarios and tie it to pain points and promise
  • NalneeshProvide overview of the the four components and why the components were important to our constituents
  • NalneeshDiscuss architecture layers
  • NalneeshProvide OverviewYou will notice alignment with the Delivery/Operations diagram Nalneesh coveredPolicies, Standards and Guidelines drive the processes and technologies.For policies, be prepared to deal with how policies get defined – contracts, policies, the second key factor here is about rationalizing conflicting policiesProcess and technologis focus on how identities are provisioned and entitled, how policies are enforced on those identities and the operational aspects of those identitiesWe list 6 process and technology areas that must be dealt with in the IDF solutionWe introduce the top down view late in the presentation to emphasize that the top down view could lead you to believe that one must always start with policies. The reality however is different as we cover in the implementation challenges as described on the next slide.
  • ZachAgain, FIDisn’t a silver bullet, and although you will have the ability to federate, you still need to federate your applications in a strategic way, and one big part of that is understanding the effort involved with each applicationAdditional Application Considerations:Policy/Regulation: data sensitivity: CFR 11, HIPAA, PIIUser characteristics:numberlocation languagesusage frequencyroles
  • ZachNotesWho do I call now? (provisioning, authn, authz)the identity provider’s processes and policiessetting expectations training providedself-servicesupport mechanisms and integration of support (IdP, SP, PM, et. al.)security approach – certificates, tokens, etc. vs. zero footprintnumber of touch points as a measure/metric of success
  • ZachSponsorshipexecutive levelMarketing/Educationpithy elevator statementsexecution teams ready?Great Expectationsa pilot is a no loss dealagree on bufferingExecutionsomeone has to be Mr. Incrediblehiccups, resourcesID Federation is expensive, but lets share with you what we would do differently, we should be prepared to share anecdotes here.As we know, flexibility lends itself to complexity, and without the right experts you won’t realize the benefits, and will have an even more uphill battleAssessment Phasebuild momentum / start the conversation - why this? why now? benefits?consider the audience and messaging – executives to “day to day”educate and involve others to create initialvision – think big, start smallPlanning Phaseuse pilots to build/maintain momentumconsider partner (IdP, SP, et. al.) needs and availabilitydon’t repeat mistakes - leverage your networkset realistic expectations - align with culture; scope, schedule, budget, returnsconsider alignment with existing initiativesExecution Phaseconduct pre-execution phase readiness test – budgets and people in place?communicate frequently – is it real?provide perspective – failure isn’t always a “bad thing”have a plan B – what if...ID Federation benefits can be measured both from a user and business perspectiveUnderstand the investment philosophy and approach up frontUse experiments / pilots to learn and mitigate riskDo your homework – understand your industry and vendorsSignup champions and market ID Federation as a business enablerPersevere to succeed!
  • ZachLeave the audience with some thought provoking questions and open up the call for questions
  • Identity Federation for the Enterprise: Lessons Learned

    1. 1. Identity Federation: Lessons From the Trenches<br />Nalneesh Gaur<br />Principal and Chief Security Architect<br /><br />Mobile – 214 649 1261<br />Zach Sachen <br />Principal<br /><br />Mobile – 541 782 8463<br />Jun 9th | 13:45 – 14:15 <br />
    2. 2. Our Journey<br />What problem did we solve?<br />How did we do it?<br />What did we learn?<br />What did we do?<br />
    3. 3. Pain and Promise<br /><ul><li>Lengthy Provisioning Process
    4. 4. Repetitive, Redundant, Different
    5. 5. “Slow Trust”
    6. 6. Collaboration / “User” Growth
    7. 7. Cumbersome Authorization
    8. 8. Cost</li></ul>What problem did we solve?<br /><ul><li>Improved User Experience
    9. 9. Faster Secured Collaboration
    10. 10. Fewer IDs
    11. 11. Additional Security Options
    12. 12. “Built-in” Compliance
    13. 13. Economies of Scale</li></li></ul><li>Context<br />What did we do?<br />Internally Managed Application<br />External User<br />Internal User<br />Externally Managed Application<br />
    14. 14. Federated ID Solution Components<br />How did we do it?<br />While additional Components are conceivable, these four components are fundamental to every ID Federation solution<br />
    15. 15. Architecture<br />How did we do it?<br />Architecture is influenced by:<br />Communities<br />Trust Relationships<br />Entitlements<br />
    16. 16. Process and Policy<br />How did we do it?<br />Policy, Standards and Guidelines<br />Process & Technology<br />Administration<br />Self Service<br />Reporting<br />Management<br />Enforcement<br />Architecture Review<br />Policy<br />Legal<br />Provisioning & Entitlement<br />
    17. 17. Applications<br />How did we do it?<br />Classification Framework<br />Many factors determine effort to federate an application, we have found two major factors:<br />1) native federationsupport <br />2) level of customization<br />IV<br />III<br />Non- Native(e.g. local authn.)<br />High Effort<br />Medium Effort<br />Federation Support<br />I<br />II<br />Native (e.g. SAML)<br />Low/Medium Effort<br />Low Effort<br />COTS<br />Custom<br />Level of Customization<br />1 – There are technologies which can deliver “virtual federation” in a relatively easy manner – e.g. Citrix and Microsoft product combinations<br />
    18. 18. User Experience<br />How did we do it?<br />Setting the Vision<br />Setting Expectations <br />Self-service<br />Training<br />Solution Support<br />
    19. 19. Success Notes and Lessons Learned<br />The Results!<br />What did we learn?<br /><ul><li>Pilot Value
    20. 20. Marketing/Education
    21. 21. Great Expectations
    22. 22. Execution Challenges
    23. 23. Journey Implications</li></ul>Source: Disney Pictures – “The Incredibles – Rise of the Underminer”<br />
    24. 24. Thank You<br /><ul><li>Should the first wave of ID Federation be internally or externally focused?
    25. 25. How to position Identity Federation as a catalyst for strong authentication?
    26. 26. Should business leverage ID Federation as the spring board to get on the social media bandwagon?</li>