Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SSO Strategy Implementation Considerations


Published on

Published in: Technology
  • Be the first to comment

SSO Strategy Implementation Considerations

  1. 1. SSO Strategy Implementation Considerations July 8, 2010
  2. 2. Agenda <ul><li>Why listen to this @jfbauer guy on SSO? </li></ul><ul><li>Agree on Terminology </li></ul><ul><li>Current Landscape </li></ul><ul><li>SSO Utopia </li></ul><ul><li>Application – Framework View </li></ul><ul><li>Future State </li></ul><ul><li>Roadmap </li></ul>
  3. 3. Why listen to this @jfbauer guy on SSO? <ul><li>SSO Related Speaking Engagements </li></ul><ul><li>Nov. 2008 CA World, Identity and Access Management </li></ul><ul><li>Sept. 2008 Oracle OpenWorld, Identity and Access Management </li></ul><ul><li>Aug. 2008, CA IAM Conference, Houston, TX </li></ul><ul><li>July 2008, Medical Mutual IAM Conference, Cleveland, OH </li></ul><ul><li>Nov. 2007, Gartner Identity and Access Management Conference, Los Angeles, CA </li></ul><ul><li>Nov. 2007, Oracle OpenWorld, Online Real-time Fraud Detection </li></ul><ul><li>Aug. 2007, Oracle NEO Enterprise Architecture Quarterly </li></ul><ul><li>June 2006, NACHA Authentication conference, Reston, VA </li></ul>
  4. 4. Agree on Terminology Single Sign-On? LDAP vs. Active Directory? Authentication vs. Authorization? Build vs. Buy? Vendor Solutions? TAM vs. SiteMinder vs. OAM? Security = Inverse of Convenience? Directory of Record? How/When to “Integrate?” Roadmap? Entitlements? IAM?
  5. 5. Agree on Terminology <ul><li>First step, establish definitions for terminology so we can all speak the same language </li></ul>
  6. 6. Agree on Terminology <ul><li>Single Sign-On = Ability for a single individual to use one single set of credentials (ex. user name + password) to access multiple applications they use with applications </li></ul><ul><li>Authentication = Simply an individual providing credentials to prove who they are </li></ul><ul><ul><li>I’m really Bob, not Mary </li></ul></ul>
  7. 7. Agree on Terminology <ul><li>Authorization = Simply verifying if an authenticated individual has been granted access to an application </li></ul><ul><ul><li>I’m Bob and I can access Application X </li></ul></ul><ul><li>Audit = Recording in a log file what just occurred </li></ul><ul><ul><li>Bob successfully accessed Application X login page on 7//7/2010 at 9:01am EST </li></ul></ul>
  8. 8. Agree on Terminology <ul><li>Entitlements = Now that an individual has been authenticated and is authorized to access an application what can and can’t they do/see within that application </li></ul><ul><ul><li>I’m Bob, I can access Application X and within Application X I can view planning data and reports but I can’t change anything </li></ul></ul>
  9. 9. Agree on Terminology <ul><li>LDAP = “Lightweight Directory Access Protocol is an application protocol for querying and modifying data using directory services running over TCP/IP”* </li></ul><ul><li>Directory = “is a set of objects with attributes organized in a logical and hierarchical manner.”* </li></ul>*Source =
  10. 10. Agree on Terminology <ul><li>Active Directory = “is a technology created by Microsoft that provides a variety of network services, including: … LDAP”* </li></ul><ul><li>Kerberos = “a computer network authentication protocol, which allows nodes communicating over a non-secure network to prove their identity to one another in a secure manner”** or one way to authenticate stuff </li></ul>*Source = **Source =
  11. 11. Agree on Terminology <ul><li>IAM = “Identity and Access Management” or the IT/Security industry discipline that encompasses all this stuff (analogous to PMO for projects or ITIL for systems management, etc.) </li></ul>
  12. 12. Current Landscape <ul><li>Second step, agree on how this are currently done so we all are working from the same baseline understanding </li></ul>
  13. 13. Current Landscape <ul><li>Everyone solves the 3 A’s within their own solution domain </li></ul><ul><ul><li>3 A’s = “Authentication, Authorization and Auditing” </li></ul></ul><ul><ul><li>Each project has to invest time/energy/$$$/resources to solve the same AAA problems over, and over, and over </li></ul></ul><ul><ul><li>Post project, per application AAA workflows provide on going support costs </li></ul></ul>
  14. 14. Current Landscape <ul><li>Um, err, business case here??? </li></ul><ul><ul><li>International Data Group reports that an average user in a 10,000-employee company has 14 separate passwords. </li></ul></ul><ul><ul><li>Forrester, “Password problems and resets generally constitute between 25% and 40% of total help desk incidents”* </li></ul></ul>*Source = Twenty-three Best Practices For the Customer Service Center, Chip Gliedman, Forrester, 10/11/2005
  15. 15. Current Landscape <ul><li>Long story short … if an organization continues to grow without an SSO strategy + solution, the costs associated with managing user application access (AAA) will proportionally increase </li></ul>
  16. 16. SSO Utopia <ul><li>Common service for external SSO </li></ul><ul><li>Common service for internal SSO </li></ul><ul><li>Self Service credential reset </li></ul><ul><li>Standard SSO integration path for all project solutions/applications </li></ul><ul><li>TOC for IAM reduced across the enterprise </li></ul><ul><li>Raises for everyone in IT </li></ul>
  17. 17. Application – Framework View <ul><li>More realistically: </li></ul>
  18. 18. Future State Approach Pros Cons In-House Developed Solution <ul><li>Control over entire feature set </li></ul><ul><li>Lack of vendor dependencies </li></ul><ul><li>Deep internal SME over solution </li></ul><ul><li>Will take longer </li></ul><ul><li>Will require a larger team to execute. </li></ul><ul><li>Longer delay to benefiting from ROI </li></ul><ul><li>Lack of inherent competency in this space. </li></ul><ul><li>Resource attrition takes away irreplaceable knowledge thus reducing initial approach value </li></ul>Purchase Vendor Framework <ul><li>Already mature product options in the marketplace </li></ul><ul><li>Top tier vendors investing in this space (CA, Oracle, IBM, etc.) </li></ul><ul><li>Faster realization of outlined benefits </li></ul><ul><li>Leverage vendor expertise to augment internal resources as needed </li></ul><ul><li>Will incur licensing and support cost from selected vendor. </li></ul><ul><li>Will involve normal vendor product lifecycle management challenges (version upgrades, product road maps, custom feature sets) </li></ul>
  19. 19. Roadmap <ul><li>Agree on definitions </li></ul><ul><li>Agree on SSO utopia future state </li></ul><ul><li>Agree on strategic Auth and Az stores </li></ul><ul><ul><li>Example: LDAP for all external users? </li></ul></ul><ul><ul><li>Example: AD for internal/employees? </li></ul></ul><ul><li>Agree on initial SSO integration approach </li></ul><ul><ul><li>New project designs w/SSO after X date </li></ul></ul><ul><ul><li>or retrofit N existing applications </li></ul></ul><ul><ul><li>or “Major project Y and then …” </li></ul></ul><ul><ul><li>or some other criteria??? </li></ul></ul>
  20. 20. Roadmap <ul><li>Evaluate/RFI/RFP vendor landscape </li></ul><ul><ul><li>Short list </li></ul></ul><ul><ul><ul><li>Example: CA, Oracle and IBM </li></ul></ul></ul><ul><ul><ul><li>Consider Gartner “magic quadrant” and existing vendor relationships </li></ul></ul></ul><ul><li>Vendor POC including “integration service” modeling </li></ul><ul><ul><li>Legacy/Project integration criteria </li></ul></ul><ul><ul><li>FTE/staffing to support </li></ul></ul><ul><li>Production deployment </li></ul><ul><li>Integrations! </li></ul>
  21. 21. ? Graphics blatantly stolen with approval from @jurgenappelo