Push, Pull, or Punt - Identity management tug-of-war: Then, Now, and Beyond
•
9 gefällt mir•27,763 views
This document discusses push, pull, and punt approaches to identity management and authorization. It summarizes the evolution from push-based provisioning to emerging pull-centric architectures that externalize authorization decisions. While push is commonly used today, pull-based identity management that centrally manages authorization policies is an emerging design pattern that provides better visibility, control and auditability over user access and entitlements. However, external authorization is still gaining vendor support and widespread adoption.
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Push, Pull, or Punt - Identity management tug-of-war: Then, Now, and Beyond
Ähnlich wie Push, Pull, or Punt - Identity management tug-of-war: Then, Now, and Beyond (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
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
- 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?
- 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
- 11. 1.Membership
- 13. Membership Clause • Governs eligibility • Can be static • Membership in business role • Can be dynamic • (orgUnitId in (102,103,53,142)) • Or combinations of both
- 14. 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
- 15. Build approval processes
- 16. Build and/or reuse fulfillment mechanisms
- 17. 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
- 18. Push bits into managed resources
- 19. Review as needed
- 20. Access Certification • Increasingly important in enterprise • SP 800-53 AC-2 • Rise of Identity and Access Governance • Separates operations from management
- 22. Spray old data everywhere
- 23. Managed systems never built to be remotely managed
- 24. Manage systems never built to externalize authorization decisions
- 25. What are we doing today Push in a Federation
- 29. Start building SAML metadata
- 30. Hub and Spoke
- 31. Network of peers
- 32. Map local attributes to RPs entitlements and attributes
- 35. Action at a distance
- 36. Telekinesis
- 37. Telekinesis • Want to effect the authorizations in a remote system
- 38. Telekinesis • Want to effect the authorizations in a remote system • Provisioning local objects to effect remote authorization state
- 39. Telekinesis • Want to effect the authorizations in a remote system • Provisioning local objects to effect remote authorization state • But this is a hoax
- 40. 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
- 42. Spray old data everywhere
- 43. Spray old data everywhere • But now with less visibility
- 44. Spray old data everywhere • But now with less visibility • RPs don’t know the quality of the data
- 45. 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
- 46. 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
- 48. SPML = push
- 49. SAML = push & pull
- 50. Proprietary APIs = push / pull
- 51. LDAP = pull
- 52. No one best approach
- 53. Emerging architecture of identity management Pull
- 55. Determine authorization policies
- 57. 1.Membership
- 60. Context • Time of day • Authenticator type • Geolocation • Transaction “value”
- 61. Identify authoritative sources
- 66. But my apps don’t know how to do that!
- 67. Push policies to XACMLoids
- 69. Where is the market?
- 70. Pull-centric identity architecture is just beginning to emerge
- 71. Last year was a quiet year for finer-grained authorization
- 72. External authZ is gaining vendor traction
- 73. • Oracle Entitlement Server • Microsoft Active Directory Federation Services v2 • Axiomatics
- 74. But it doesn’t have a lot of momentum yet
- 75. Use cases we see are:
- 77. Bespoke systems where EA has a had a strong voice
- 78. ADFS v2, Geneva, & SharePoint 2010
- 79. But as a design pattern
- 82. Amusement Park Parable This tall to ride
- 83. Goal: Authorize people to ride
- 86. PDP
- 87. PDP Not authorized
- 88. You carry claims
- 89. Do not treat height as token for relationship
- 91. Do not use height as an entitlement
- 93. Don’t confuse attributes for relationships
- 94. Don’t mistake attributes for entitlements
- 96. You must be as tall as the Speedzone logo to drive this car
- 97. You must be as tall as the Speedzone logo to drive this car
- 103. But I wanna go on the ride...
- 104. But I wanna go on the ride... • I’m tall enough
- 105. But I wanna go on the ride... • I’m tall enough • But Mom doesn’t want me to ride the ride
- 106. 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?
- 107. 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?
- 109. Push, Pull, Punt A way forward
- 110. The business of identity providers
- 112. Federated virtual directory
- 114. Rise of the XACMLoids
- 116. Cache and Stash
- 118. Apps aren’t built for this
- 120. Audit patterns
- 122. Regardless whether you
- 123. push, pull, or punt
- 124. IdM is changing under your feet
- 125. 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
- 126. Images courtesy of • croweb • sundazed • nickso • andy castro • Graham • tkksummers Ballantyne • spacesuitcatalyst
Hinweis der Redaktion
- The problems with push Image courtesy of croweb - http://www.flickr.com/photos/croweb/2904702979
- 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.
- 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/
- 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
- Provisioning locally is (barely) tolerable. Provisioning locally and remotely is wasted effort.
- Provisioning locally is (barely) tolerable. Provisioning locally and remotely is wasted effort.
- Provisioning locally is (barely) tolerable. Provisioning locally and remotely is wasted effort.
- Provisioning locally is (barely) tolerable. Provisioning locally and remotely is wasted effort.
- The problems with push in a federated environment: federated provisioning Image courtesy of croweb - http://www.flickr.com/photos/croweb/2904702979
- A variety of approaches have been taken to try and solve the challenge of federated provisioning.
- 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.
- 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.
- Cloud providers have been building their own provisioning interfaces using neither the SAML or SPML standards.
- A few service providers have offered LDAP as a means of provisioning. In some cases, a provider can issue LDAP queries to the enterprise.
- Needless to say, there is no one best approach. Or at least, there is no one agreed upon approach.
- Same basic idea as cataloging entitlements.
- These policies seem similar to provisioning policies but they have an extra clause - Context.
- These policies seem similar to provisioning policies but they have an extra clause - Context.
- These policies seem similar to provisioning policies but they have an extra clause - Context.
- The above are example of contextual items that can be considered during an authorization event.
- 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.
- 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.
- We’ll add another step to accommodate applications that don’t know how to ask for external information to make authorization decisions.
- The XAMLoids know how to ask the FVD for information and then can present the go/no-go decision to the endpoint.
- We expect SharePoint2010 as the “infection vector” by which claims-aware computing becomes popular in the enterprise.
- To authorize people, the amusement park installs a sign at a given heigh. Image courtesy of sundazed - http://www.flickr.com/photos/sundazed/555071016/
- To authorize people, the amusement park installs a sign at a given heigh. Image courtesy of sundazed - http://www.flickr.com/photos/sundazed/555071016/
- That’s what a ticket is for. Image courtesy of andycastro - http://www.flickr.com/photos/andycastro/2615845976/
- That’s what the date on the ticket is for. Image courtesy of andycastro - http://www.flickr.com/photos/andycastro/2615845976/
- This is a great policy but it is awfully hard to audit. Image courtesy of tkksummers - http://www.flickr.com/photos/tkksummers/2888454076/
- This is a great policy but it is awfully hard to audit. Image courtesy of tkksummers - http://www.flickr.com/photos/tkksummers/2888454076/
- This is a great policy but it is awfully hard to audit. Image courtesy of tkksummers - http://www.flickr.com/photos/tkksummers/2888454076/
- This is a great policy but it is awfully hard to audit. Image courtesy of tkksummers - http://www.flickr.com/photos/tkksummers/2888454076/
- Consider you build the policy above. Image courtesy of spacesuitcatalyst - http://www.flickr.com/photos/spacesuitcatalyst/438010405/
- Someone arrives with a claim that looks like the above. Image courtesy of spacesuitcatalyst - http://www.flickr.com/photos/spacesuitcatalyst/438010405/
- This is the policy you meant to write. Image courtesy of spacesuitcatalyst - http://www.flickr.com/photos/spacesuitcatalyst/438010405/
- 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.
- 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.
- 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.
- 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.
- 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
- All images unless otherwise sourced where found on Flickr