Advertisement

Push, Pull, or Punt - Identity management tug-of-war: Then, Now, and Beyond

Chair, ID Pro Discussion Group at Kantara Initiative
Jul. 20, 2010
Advertisement

More Related Content

Similar to Push, Pull, or Punt - Identity management tug-of-war: Then, Now, and Beyond(20)

Advertisement

Push, Pull, or Punt - Identity management tug-of-war: Then, Now, and Beyond

  1. Push, Pull, or Punt?! Identity tug-of-war: then, now & beyond Ian Glazer Research Director, Gartner ian.glazer@gartner.com @iglazer
  2. What are we doing today Push in the Enterprise
  3. Catalog entitlements
  4. Entitlements • The highest-order assignable object in a security model • Cataloging is more than just names • Descriptions and meanings • Owners, risk, sensitivity
  5. Group them
  6. Bundles of entitlements • Technical roles • But that name is losing cachet • What has to be assigned to make business function X go?
  7. Build business roles
  8. Roles • Multiple attempts to build role models • Regular, semi-homogenous orgs work best • Don’t try this with development shops • No silver bullets have ever or will ever exist
  9. Build (provisioning) policies
  10. 1.Membership
  11. 1.Membership 2.Attributes & Entitlements
  12. Membership Clause • Governs eligibility • Can be static • Membership in business role • Can be dynamic • (orgUnitId in (102,103,53,142)) • Or combinations of both
  13. Attributes & Entitlements • Describes what needs to be set in target systems • Could be pointers to bundles of entitlements • More likely pointers + some attributes that also need to be set
  14. Build approval processes
  15. Build and/or reuse fulfillment mechanisms
  16. Fulfill this! • Need to set attributes and assign entitlements in the target systems • How that is done is less and less important • User provisioning • Help Desk ticket • Email • Directory sync
  17. Push bits into managed resources
  18. Review as needed
  19. Access Certification • Increasingly important in enterprise • SP 800-53 AC-2 • Rise of Identity and Access Governance • Separates operations from management
  20. Spray old data everywhere
  21. Managed systems never built to be remotely managed
  22. Manage systems never built to externalize authorization decisions
  23. What are we doing today Push in a Federation
  24. Sign business agreement
  25. Determine RPs needs
  26. • Attributes • Entitlements
  27. Start building SAML metadata
  28. Hub and Spoke
  29. Network of peers
  30. Map local attributes to RPs entitlements and attributes
  31. Perform telekinesis
  32. Perform telekinesis?
  33. Action at a distance
  34. Telekinesis
  35. Telekinesis • Want to effect the authorizations in a remote system
  36. Telekinesis • Want to effect the authorizations in a remote system • Provisioning local objects to effect remote authorization state
  37. Telekinesis • Want to effect the authorizations in a remote system • Provisioning local objects to effect remote authorization state • But this is a hoax
  38. Telekinesis • Want to effect the authorizations in a remote system • Provisioning local objects to effect remote authorization state • But this is a hoax • Provision remote objects too
  39. Spray old data everywhere
  40. Spray old data everywhere • But now with less visibility
  41. Spray old data everywhere • But now with less visibility • RPs don’t know the quality of the data
  42. Spray old data everywhere • But now with less visibility • RPs don’t know the quality of the data • RPs don’t know the data’s “Sell By” date
  43. Spray old data everywhere • But now with less visibility • RPs don’t know the quality of the data • RPs don’t know the data’s “Sell By” date • Information sources don’t always know where the data went
  44. Federated provisioning
  45. SPML = push
  46. SAML = push & pull
  47. Proprietary APIs = push / pull
  48. LDAP = pull
  49. No one best approach
  50. Emerging architecture of identity management Pull
  51. Catalog capabilities
  52. Determine authorization policies
  53. 1.Membership
  54. 1.Membership 2.Attributes & Entitlements
  55. 1.Membership 2.Attributes & Entitlements 3.Context
  56. Context • Time of day • Authenticator type • Geolocation • Transaction “value”
  57. Identify authoritative sources
  58. Codify access policies
  59. Authorize & enforce
  60. But my apps don’t know how to do that!
  61. Push policies to XACMLoids
  62. Where is the market?
  63. Pull-centric identity architecture is just beginning to emerge
  64. Last year was a quiet year for finer-grained authorization
  65. External authZ is gaining vendor traction
  66. • Oracle Entitlement Server • Microsoft Active Directory Federation Services v2 • Axiomatics
  67. But it doesn’t have a lot of momentum yet
  68. Use cases we see are:
  69. Internal, non-federation
  70. Bespoke systems where EA has a had a strong voice
  71. ADFS v2, Geneva, & SharePoint 2010
  72. But as a design pattern
  73. external authorization
  74. doesn’t have wide-spread mindshare
  75. Amusement Park Parable This tall to ride
  76. Goal: Authorize people to ride
  77. Condition: No existing agreement
  78. PDP
  79. PDP Not authorized
  80. You carry claims
  81. Do not treat height as token for relationship
  82. Do not use height as an entitlement
  83. Don’t confuse attributes for relationships
  84. Don’t mistake attributes for entitlements
  85. You must be as tall as the Speedzone logo to drive this car
  86. You must be as tall as the Speedzone logo to drive this car
  87. Auditing challenges
  88. Problems validating policy
  89. But I wanna go on the ride...
  90. But I wanna go on the ride... • I’m tall enough
  91. But I wanna go on the ride... • I’m tall enough • But Mom doesn’t want me to ride the ride
  92. But I wanna go on the ride... • I’m tall enough • But Mom doesn’t want me to ride the ride • How does her “policy” get represented?
  93. But I wanna go on the ride... • I’m tall enough • But Mom doesn’t want me to ride the ride • How does her “policy” get represented? • How is it acted upon?
  94. Inappropriate authorizations
  95. Push, Pull, Punt A way forward
  96. The business of identity providers
  97. Federated virtual directory
  98. Rise of the XACMLoids
  99. Cache and Stash
  100. Apps aren’t built for this
  101. Audit patterns
  102. Regardless whether you
  103. push, pull, or punt
  104. IdM is changing under your feet
  105. Reference • Gartner ITP / Burton Group Research • The Emergent Architecture for Identity Management - Bob Blakley • Provisioning’s Role in the Next-Generation IdM Architecture - Lori Rowland • Characteristics of an Effective Identity Management Governance Program - Kevin Kampman • Market Profile: Identity and Access Governance 2010 - Ian Glazer & Mark Diodati
  106. Images courtesy of • croweb • sundazed • nickso • andy castro • Graham • tkksummers Ballantyne • spacesuitcatalyst

Editor's Notes

  1. The problems with push Image courtesy of croweb - http://www.flickr.com/photos/croweb/2904702979
  2. Think about a typical COTS application. Users and their privileges are managed within the app and often there is very little in terms of remote user management capabilities. This has led to some of the complexities in user provisioning systems.
  3. Traditional applications of federation technology follow two deployment patterns. The first is hub and spoke in which a heavy-weight company is the center of the federation and its trading partners federate on the hub’s terms. Image courtesy of nickso - http://www.flickr.com/photos/nickso/3045996440/
  4. The second federation deployment pattern is the network of peers. With no heave-weight at the center, the federation is composed of peers who federate amongst each other. Image courtesy of Graham Ballantyne - http://www.flickr.com/photos/grahamb/2355477036/in/pool-324690@N20
  5. Provisioning locally is (barely) tolerable. Provisioning locally and remotely is wasted effort.
  6. Provisioning locally is (barely) tolerable. Provisioning locally and remotely is wasted effort.
  7. Provisioning locally is (barely) tolerable. Provisioning locally and remotely is wasted effort.
  8. Provisioning locally is (barely) tolerable. Provisioning locally and remotely is wasted effort.
  9. The problems with push in a federated environment: federated provisioning Image courtesy of croweb - http://www.flickr.com/photos/croweb/2904702979
  10. A variety of approaches have been taken to try and solve the challenge of federated provisioning.
  11. One approach was to use SPML. First, not all service providers have an SPML interface. Second, not every enterprise has a provisioning process that can generate SPML messages.
  12. Another approach is to use SAML. There have been two approaches to this. One is to establish an agreement that requires more than needed to perform authentication. This extra data is used back a backend provisioning process. The problem with this approach is that this data always is sent which can violate the privacy principle of data minimization among other things. The second approach is to use Metadata-Exchange to facilitate attribute exchange on an as-needed basis.
  13. Cloud providers have been building their own provisioning interfaces using neither the SAML or SPML standards.
  14. A few service providers have offered LDAP as a means of provisioning. In some cases, a provider can issue LDAP queries to the enterprise.
  15. Needless to say, there is no one best approach. Or at least, there is no one agreed upon approach.
  16. Same basic idea as cataloging entitlements.
  17. These policies seem similar to provisioning policies but they have an extra clause - Context.
  18. These policies seem similar to provisioning policies but they have an extra clause - Context.
  19. These policies seem similar to provisioning policies but they have an extra clause - Context.
  20. The above are example of contextual items that can be considered during an authorization event.
  21. No single provider has close relationships with all the individuals a modern enterprise needs to deal with. So no organization can be a sole-source provider of low-cost, high-quality provider of all the identities an enterprise needs.
  22. This is what a pull-based authorization systems looks like. A user initiates an action in a system that system asks the federated virtual directory (FVD) for all of the data needed to make the authorization decision. The FVD returns that data to the endpoint which makes a go/no-go authorization decision.
  23. We’ll add another step to accommodate applications that don’t know how to ask for external information to make authorization decisions.
  24. The XAMLoids know how to ask the FVD for information and then can present the go/no-go decision to the endpoint.
  25. We expect SharePoint2010 as the “infection vector” by which claims-aware computing becomes popular in the enterprise.
  26. To authorize people, the amusement park installs a sign at a given heigh. Image courtesy of sundazed - http://www.flickr.com/photos/sundazed/555071016/
  27. To authorize people, the amusement park installs a sign at a given heigh. Image courtesy of sundazed - http://www.flickr.com/photos/sundazed/555071016/
  28. That’s what a ticket is for. Image courtesy of andycastro - http://www.flickr.com/photos/andycastro/2615845976/
  29. That’s what the date on the ticket is for. Image courtesy of andycastro - http://www.flickr.com/photos/andycastro/2615845976/
  30. This is a great policy but it is awfully hard to audit. Image courtesy of tkksummers - http://www.flickr.com/photos/tkksummers/2888454076/
  31. This is a great policy but it is awfully hard to audit. Image courtesy of tkksummers - http://www.flickr.com/photos/tkksummers/2888454076/
  32. This is a great policy but it is awfully hard to audit. Image courtesy of tkksummers - http://www.flickr.com/photos/tkksummers/2888454076/
  33. This is a great policy but it is awfully hard to audit. Image courtesy of tkksummers - http://www.flickr.com/photos/tkksummers/2888454076/
  34. Consider you build the policy above. Image courtesy of spacesuitcatalyst - http://www.flickr.com/photos/spacesuitcatalyst/438010405/
  35. Someone arrives with a claim that looks like the above. Image courtesy of spacesuitcatalyst - http://www.flickr.com/photos/spacesuitcatalyst/438010405/
  36. This is the policy you meant to write. Image courtesy of spacesuitcatalyst - http://www.flickr.com/photos/spacesuitcatalyst/438010405/
  37. No single provider has close relationships with all the individuals a modern enterprise needs to deal with. So no organization can be a sole-source provider of low-cost, high-quality provider of all the identities an enterprise needs.
  38. No single provider has close relationships with all the individuals a modern enterprise needs to deal with. So no organization can be a sole-source provider of low-cost, high-quality provider of all the identities an enterprise needs.
  39. Data-intensive applications will require information to be “closer.” In these situations, the FVD and the endpoint can work with a cache or stash. Of course by adding a cache/stash, the chance that an authorization decision is made on “bad” or out-of-date data goes up.
  40. The reality is that we will have push-only applications for long time. The hybrid approach of having both push and pull in the enterprise is the more likely future.
  41. The Emerging Architecture of Identity Management - http://www.burtongroup.com/Client/Research/Document.aspx?cid=1895 Market Profile: Identity and Access Governance 2010 - http://www.burtongroup.com/Client/Research/Document.aspx?cid=1858 Characteristics of an Effective Identity Management Governance Program - http://www.burtongroup.com/Client/Research/Document.aspx?cid=1731 Provisioning’s Role in the Next-Generation IdM Architecture - http://www.burtongroup.com/Client/Research/Document.aspx?cid=1993
  42. All images unless otherwise sourced where found on Flickr
Advertisement