DO WE HAVE A ROUND WHEEL YET?
•Download as PPTX, PDF•
1 like•763 views
IAN GLAZER, Senior Director, Identity, salesforce.com, at the European IRM Summit 2014.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to DO WE HAVE A ROUND WHEEL YET?
Similar to DO WE HAVE A ROUND WHEEL YET? (20)
More from ForgeRock
More from ForgeRock (20)
Recently uploaded
Recently uploaded (20)
DO WE HAVE A ROUND WHEEL YET?
- 1. Do we have a round wheel yet? Ian Glazer Senior Director, Identity Salesforce Identity @iglazer
- 2. Why do humans continually reinvent what they already have?
- 3. 1. functional thing 2. attempt to “fix” it 3. break it 4. fix it 5. functional++ thing
- 4. Why is it that we reinvent the wheel?
- 5. Eventually we get a round one.
- 6. Why do we do this in the world of identity?
- 9. We reinvent the wheel when tasks change
- 10. SOA SOAP XML
- 14. IAM has to stay contemporary
- 15. The load our IAM wheels have to carry has changed.
- 17. Right Access Right People Right Time
- 18. Right Experience Right People Right Time
- 19. Right Experience Right People & Things Right Time
- 20. Right Experience Right People & Things Right Time Right Place
- 21. But that’s not all
- 23. firstName lastName email mobile ou nickname title … firstName lastName email mobile ou nickname title … firstName lastName email mobile ou nickname title … firstName lastName email mobile ou nickname title …
- 28. Reasonably large number of identities with a reasonable number of attributes
- 29. We are being asked to haul more and different identities
- 31. deviceID firmware deviceID firmware deviceID firmware deviceID firmware
- 38. 25,000,000,000?
- 39. 50,000,000,000?
- 40. Unreasonably large number of identities with a few attributes
- 42. Reports to Reports to Reports to Works with
- 43. Reports to Reports to Reports to Owns Works with Owns
- 44. Reports to Reports to Reports to Owns Owns Owns Gets data from Sends data to Owns Paired with Uses Controls Works with
- 45. Reports to Reports to Reports to Owns Owns Owns Gets data from Sends data to Owns Paired with Uses Controls Owns Uses Uses Constrains choice of Works with
- 46. Reports to Reports to Reports to Owns Owns Owns Gets data from Sends data to Owns Paired with Uses Controls Owns Uses Uses Constrains choice of Sends data to Ridden in Ridden in Works with
- 47. Unreasonably large number of relationships between unreasonably large numbers of people and things, each with attributes
- 49. 1. Authentication 2. Authorization 3. Attributes 4. User Provisioning
- 50. Authentication
- 52. Multiple Protocols Multiple Standards
- 54. OpenID Connect could use a few more miles on the road
- 55. But you should start today with it
- 58. What about representing identity assurance?
- 59. Can we harmonize levels of assurance?
- 60. Should we?
- 61. myLOA 2 = urLOA 3.1
- 62. You’ve been proofed. You’ve been authenticated.
- 63. So what?
- 65. Poorly deploying strong authentication makes it weak authentication.
- 66. LOA? Trust Framework? Start here?
- 68. Authentication’s wheel still has lumps
- 69. 1. Reinvention 2. IAM’s Collective Shame
- 70. Reinventing just to reinvent
- 71. OAuth A4C
- 72. OAuth A4C
- 75. The need for password vaulting
- 76. We’ve had fully workable authentication standards for years
- 77. Yet we still password vault
- 78. Not enough service provider enablement
- 79. SP’s not acting on behalf of their customers’ interests
- 81. (Standards-based user provisioning too)
- 83. Mobile-optimized authN will (hopefully) force SPs to act
- 84. Killing passwords is IAM’s new black
- 85. Killing the need for password vaulting
- 86. More reasonable More achievable More effective
- 88. 2017
- 90. Authorization
- 91. Authentication Round Authorization Not Round*
- 92. 1. Over-inflated 2. Flat
- 94. XACML can do anything
- 95. Things that allow you to do anything
- 96. tend to make it hard to do anything
- 97. Focus on the PAPs not the protocol
- 98. XACML must be contemporary
- 99. REST & JSON are good steps forward
- 101. Could be used to represent authorization decisions
- 102. Semantics of scopes?
- 104. Binding obligations = duties of actors
- 105. Still needs more miles on the road
- 106. Enterprise-to- Enterprise use cases, please?
- 108. How can a thing make a decision with more autonomy?
- 109. How can we make decisions closer to the place and time of use?
- 111. Can perform actions X, Y, and Z Can perform actions Q, W, and E
- 112. Can perform actions X, Y, and Z Can perform actions Q, W, and E
- 113. Can perform actions X, Y, and Z Can perform actions Q, W, and E
- 114. ? ?
- 115. ADD NOT ROUND WHEEL
- 116. Attributes
- 117. Authentication Round Authorization Not Round* Attributes Roundish
- 118. The Sad Magic of Commas.
- 119. 1. Access 2. Representation
- 120. Access
- 121. Optimized for the modern web?
- 122. Graph APIs UserInfo Endpoints ADAP
- 123. LDAP?
- 124. Optimized for the modern web!
- 125. Representation
- 126. Name-Value Pairs
- 127. Name-Value Pair is the new comma
- 128. Name-Value Pairs Ubiquitous ✅ Standard Schema ❌
- 129. Anyone else miss inetOrgPerson?
- 130. inetOrgPerson for a new generation?
- 131. hipsterOrgPerson
- 132. dn:cn=Barbara Jensen, ou=WhatEvs, dc=company, dc=com objectclass:top objectclass:person objectclass:hipsterOrgPerson cn: Barbara Jensen nickname: Daisy favBand: no one you’ve ever heard of whatRUHaving: Fireball with a pickleback title: social media guru twitter: @daisypop89 email: isforoldpeople@irony.aol.com postalCode: 11211 country: USA! USA! telexNumber: is that like a fax or something?
- 133. Make SCIM schema the standard?
- 134. Standardizing schema can only work in communities of interest
- 136. User Provisioning
- 137. Authentication Round Authorization Not Round* Attributes Roundish User Provisioning Near Roundish
- 138. SPML
- 139. SPML v2 was not round
- 140. DSML v2 was round
- 141. But neither are well suited for the modern web
- 143. Others is supporting it.
- 144. Others are supporting it.
- 145. Join us!
- 147. Needs more miles on the road
- 148. Solid use case representation
- 149. Employee Identity User Provisioning
- 150. Customer Identity User Provisioning
- 151. Customer Identity Profile Management
- 152. SCIM can handle both
- 153. ADD ROUNDISH WHEEL
- 154. How round are the identity wheels?
- 155. Authentication Round Authorization Not Round* Attributes Roundish User Provisioning Near Roundish
- 156. Do we need things other than wheels?
- 157. How do you discover the identity services of a service provider?
- 158. Besides RTFM?
- 159. How do you know if they use
- 160. SAML SCIM proprietary attribute API FIDO U2F?
- 161. How do we connect our orgs and our identity services?
- 162. How do we kickstart relationships without paying p2p costs?
- 163. Hubs and axles for our roundish wheels
- 164. Remove the heavy lifting for providing and consuming services
- 165. This is where we must go.
- 166. Our future
- 167. People and things more closely related
- 168. Identity as business enabler
- 169. Right Access Right People Right Time
- 170. Right Experience Right People Right Time
- 171. Right Experience Right People & Things Right Time
- 172. Right Experience Right People & Things Right Time Right Place
- 173. We are going to shoulder a heavy load.
- 174. Round wheel Workable standards
- 175. Making and measuring progress
- 176. We need a set of design considerations.
- 177. The Laws of Relationships • Acknowledgeable • Actionable • Constrainable • Contextual • Immutable •Provable •Revocable •Scalable •Transferrable
- 178. Identity Relationship Management Working Group
- 179. Joni Brennan @jonibrennan Allan Foster @guruallan
- 180. 1. Adopt standards
- 181. If you don’t, you are inventing your own wheel
- 182. That is a short-term optimized strategy at best.
- 183. If the current ones don’t work for you, bring out your use cases.
- 184. Kelly Grizzle @kelly_grizzle Nat Sakimura @_nat Leif Johansson @leifjohansson Maciej Machulak @mmachulak John Bradley @ve7jtb
- 185. 2. Help others to adopt
- 186. Build SDKs to help people use OpenID and SAML
- 187. Support open source implementations of SCIM and OAuth
- 188. Start with your organization’s developers,
- 189. then help the community.
- 190. 3. Demand standards
- 191. From your identity technology providers.
- 192. Demand standards
- 193. From your business service providers.
- 194. Demand standards
- 195. From your own developer teams.
- 196. Demand standards
- 197. If for no other reason than to kill off the need for password vaulting.
- 198. Demand standards
- 199. A round wheel ≠ the goal
- 200. A great spec is satisfying
- 201. Pamela Dingle @pamelarosiedee Chuck Mortimore @cmort Eve Maler @xmlgrrl A great spec is satisfying David Brossard @davidjbrossard Susan Morrow @avocoidentity Brian Campbell @__b_c
- 202. but it isn’t the end goal.
- 203. We reinvent the wheel,
- 204. we revisit and rebuild our standards
- 205. to get round, beautifully functioning ones
- 206. to carry the loads we must shoulder,
- 207. to get us where we need to go
- 208. in this era of modern identity.
- 209. Thanks!
Editor's Notes
- Why do human continually seem to reinvent what they already have? Why is it that we take a reasonably functional thing and attempt to rebuild it and in doing so render that reasonably functional thing non-functional for a while? Why is it that we reinvent the wheel?
- Why is it that we take a reasonably functional thing and attempt to rebuild it and in doing so render that reasonably functional thing non-functional for a while?
- Because eventually, we get a round one. Anyone who has worked on technical standards, especially identity standards, recognizes this pattern. We build reasonably workable standards only to rebuild and recast them a few years later.
- We do this not because we develop some horrid allergy to angle brackets, an allergy that can only be calmed by mustache braces. This is not why we reinvent the wheel, why we revisit and rebuild our standards. Furthermore, revisiting and rebuilding standards isn’t simply a “make-work” affair for this guy (insert picture of Tony in Google t-shirt
- We reinvent the wheel the tasks needed of those wheels change. In IAM, the shift from SOA, SOAP, and XML to little s services, REST, and JSON was profound. And we had to stay contemporary with the way the web and developers worked. In this case, the technical load that our IAM wheels had to carry changed.
- But there is a more profound change to the tasks we must perform and the loads we must transport and it too will require us to examine our standards and see if they are up to the task.
- It used to be that enterprise IAM was concerned with answering did the right people get the right access. But that is increasingly not the relevant question. The question we must answer is did the right people get the right experience? IAM is in the midst of a transformation in order to serve customers, citizens, and even our “thing.”
- It used to be that enterprise IAM was concerned with answering did the right people get the right access. But that is increasingly not the relevant question. The question we must answer is did the right people get the right experience? IAM is in the midst of a transformation in order to serve customers, citizens, and even our “thing.”
- It used to be that enterprise IAM was concerned with answering did the right people get the right access. But that is increasingly not the relevant question. The question we must answer is did the right people get the right experience? IAM is in the midst of a transformation in order to serve customers, citizens, and even our “thing.”
- It used to be that enterprise IAM was concerned with answering did the right people get the right access. But that is increasingly not the relevant question. The question we must answer is did the right people get the right experience? IAM is in the midst of a transformation in order to serve customers, citizens, and even our “thing.”
- IAM is really good at a reasonable number of identities with a lot of attributes
- but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- but how well will it hold up when we have a completely unreasonable number of identities with very few attributes?
- 25B according to Gartner.
- 50B according to Cisco. I guess we know who has more to gain
- IAM can handle some amount relationships
- But this transition is not just from managing identities of people carbon-based life forms to silicon ones. Today we are okay at managing a few relationships each with very few attributes. But what we as an industry must do is manage a completely unreasonable number of relationships between an unreasonable number of things and each of these relationships has a fair number of attributes of their own. That, my friends, is a heavy load to haul.
- Let’s consider identity standards and their “roundness” Image courtesy of NARA: https://upload.wikimedia.org/wikipedia/commons/thumb/f/fa/As_this_big_pile_of_used_auto_tires_indicates%2C_the_United_States_with_its_many_passenger_cars_has_in_discarded_tires..._-_NARA_-_535587.tif/lossy-page1-1244px-As_this_big_pile_of_used_auto_tires_indicates%2C_the_United_States_with_its_many_passenger_cars_has_in_discarded_tires..._-_NARA_-_535587.tif.jpg
- Overall, I’d say the authentication wheel is round, maybe could use a little air, but its round. We’ve got multiple protocols, multiple standards, which is both a reflection of the complexity of the problem and the maturity of the problem. Now some of these protocols do need a few more miles on them – OpenID Connect but by no means does this mean you shouldn’t use it today. Expect new profiles over time but you certainly can get going today. And where OpenID Connect cannot take you, trusty SAML still can. Although authentication is okay, representing assurance isn’t. I wonder if we need to harmonize level of assurance. I also wonder if this is even possible. Knowing that a person was proofed and how they were authenticated is nice, but as Mark D will be the first to tell you deployment matters. You can deploy a strong auth technology poorly rendering into a weaker state. So knowing your LOA 3 is my LOA 2.25 might not be useful. More importantly, I wonder how small and medium sized organizations, those without a resident identity dork, figure out what LOA to require, what trust framework to use, and how to proceed. This to me, seems like a place for the IDESG and its ilk. And although the authentication wheel is round, that doesn’t mean it isn’t without its lumps. First, we do see some reinventing the wheel just to reinvent the wheel. OAuth A4C is simply not a fruitful activity. Second, the fact that password vaulting exists at this point in history is an embarrassment. To be clear, I am not saying that password vaulting solutions and vendors are an embarrassment. The fact that, having had workable authentication standards for this many years and we still have password vaulting is an embarrassment to our profession. It means that identity vendors have not done enough to enable service providers. It means that service providers still exist who do not want to operate in the best interest of their enterprise customers. At the minimum those service provider must offer a standards-based approach to authentication (and user provisioning would be nice too.) The existence of password vaulting means that organizations haven’t been loud enough in their demands for a better login experience. Interestingly enough, I think the need for a mobile-optimized authentication experience will force service providers hands. I know we are all trying to kill the password but I think a more reasonable, more achievable, and more effective goal is to eliminate the need for password vaulting through the use of authentication and federated SSO standards. By 2020, if I am still saying this, we have failed.
- Authentication’s wheel is round! Could use a bit of air but pretty good
- Expect new profiles over time but you certainly can get going today.
- If OpenID Connect can’t get you there today…
- SAML can
- Although authentication is okay, representing assurance isn’t. I wonder if we need to harmonize level of assurance. I also wonder if this is even possible. Knowing that a person was proofed and how they were authenticated is nice, but as Mark D will be the first to tell you deployment matters. You can deploy a strong auth technology poorly rendering into a weaker state. So knowing your LOA 3 is my LOA 2.25 might not be useful. More importantly, I wonder how small and medium sized organizations, those without a resident identity dork, figure out what LOA to require, what trust framework to use, and how to proceed. This to me, seems like a place for the IDESG and its ilk.
- Knowing that a person was proofed and how they were authenticated is nice
- So knowing your LOA 3 is my LOA 2.25 might not be useful.
- More importantly, I wonder how small and medium sized organizations, those without a resident identity dork, figure out what LOA to require, what trust framework to use, and how to proceed. This to me, seems like a place for the IDESG and its ilk.
- IDESG to the rescue?
- And although the authentication wheel is round, that doesn’t mean it isn’t without its lumps. First, we do see some reinventing the wheel just to reinvent the wheel. OAuth A4C is simply not a fruitful activity. Second, the fact that password vaulting exists at this point in history is an embarrassment. To be clear, I am not saying that password vaulting solutions and vendors are an embarrassment. The fact that, having had workable authentication standards for this many years and we still have password vaulting is an embarrassment to our profession. It means that identity vendors have not done enough to enable service providers. It means that service providers still exist who do not want to operate in the best interest of their enterprise customers. At the minimum those service provider must offer a standards-based approach to authentication (and user provisioning would be nice too.) The existence of password vaulting means that organizations haven’t been loud enough in their demands for a better login experience. Interestingly enough, I think the need for a mobile-optimized authentication experience will force service providers hands.
- OAuth A4C is simply not a fruitful activity
- OAuth A4C is simply not a fruitful activity
- Second, the fact that password vaulting exists at this point in history is an embarrassment. To be clear, I am not saying that password vaulting solutions and vendors are an embarrassment.
- The fact that, having had workable authentication standards for this many years and we still have password vaulting is an embarrassment to our profession. It means that identity vendors have not done enough to enable service providers. It means that service providers still exist who do not want to operate in the best interest of their enterprise customers. At the minimum those service provider must offer a standards-based approach to authentication (and user provisioning would be nice too.) The existence of password vaulting means that organizations haven’t been loud enough in their demands for a better login experience. Interestingly enough, I think the need for a mobile-optimized authentication experience will force service providers hands.
- t means that identity vendors have not done enough to enable service providers.
- It means that service providers still exist who do not want to operate in the best interest of their enterprise customers.
- At the minimum those service provider must offer a standards-based approach to authentication (and user provisioning would be nice too.) The existence of password vaulting means that organizations haven’t been loud enough in their demands for a better login experience. Interestingly enough, I think the need for a mobile-optimized authentication experience will force service providers hands.
- We need organizations to be louder in their demands. Image courtesy of Joe Mills: https://www.flickr.com/photos/joedm/2255363378
- I know a little something about killing off bits of IAM… I know we are all trying to kill the password but I think a more reasonable, more achievable, and more effective goal is to eliminate the need for password vaulting through the use of authentication and federated SSO standards. By 2020, if I am still saying this, we have failed.
- By 2017, if I am still saying this, we have failed.
- The authentication wheel is round Image courtesy of Craig Sunter https://www.flickr.com/photos/16210667@N02/12013320215
- Authorization’s wheel is not round in an interesting way
- XACML can do anything; it really is an amazing standard. But the problem with things that allow you to do anything is that they tend to make it hard to do something. The JSON binding is a great start to make XACML more relevant for the modern web. One challenge exists as to how to represent the output of an authorization decision. Once a decision is made, how does the result get communicated to various enforcement points along the way? Certainly OAuth and scopes can be used for that. But this requires an understand of the semantics of scopes, which isn’t a bad thing but it is a thing… service providers have to invest time to understand that. Also there are those who believe bearer tokens are hellspawn… so there’s that too.
- The JSON binding is a great start to make XACML more relevant for the modern web.
- We might be able to employ OAuth and scopes.
- Could be used to represent the output of an authZ decision
- But this requires an understanding of the semantics of scopes, which isn’t a bad thing but it is a thing… service providers have to invest time to understand that.
- What about UMA? It definitely holds promise, especially when we consider the duties of all the parties involved in managing and enforcement access to resources. I really like the idea of a standard that has a profile that describes duties of the actors separate from the wireline protocol description. UMA definitely needs more miles on the road and to be perfectly honest I still have a hard time understanding it in an enterprise context. Maybe now that Eve is coming back to the product world, the community will get more UMA awesomeness.
- There is another thing to think about as we study the roundness of the authorization wheel. Knowing that the load we will have to carry is a heavy one and one that includes “things” I think we need to think about how those “things” can make decisions with more autonomy. How can our authorization systems make authorization decision closer to the place of use at the time of use? As I have been thinking about identity relationship management, I’ve been sketching some design constraints, some laws. This is the law of relationships – Actionable. How can we make relationships actionable so that a thing, an agent, a whatever, can act on the existence of a relationship without always having to consult a back-end authorization service? (use slides from IRM deck)
- Relationships must be able to carry authorization data
- Relationships must be able to carry authorization data to account for situations when the backend service cannot be reached
- Relationships must be able to carry authorization data to account for situations when the backend service cannot be reached
- Authorization’s wheel is not round… in an interesting way Image courtesy of Judith Doyle https://www.flickr.com/photos/doyland/6688993219
- The wheel of attributes is more round than not. Now, this is not a diatribe against commas and their sad magic. There are two parts to the attribute story: access and representation. We can access attributes… sorta. There’s no clear winner that is optimized for the modern web. We’ve got graph APIs, ADAP, and UserInfo Endpoints – not to mention proprietary APIs as well. Notice I added the constraint of “optimized for the modern web.” If remove that constraint, then we could say that access to attributes is a fully solved problem: LDAP. But we are going to a protocol that enables workers in the modern web to access attributes. As for a standardized representation… we have one. Name-value pairs. In fact, name-value pairs might be the new comma. (Ian speaks into cellphone “Siri, remind me to kill name-value pairs next year.) And although NVP are ubiquitous, we don’t have a standard schema. What is the inetOrgPerson of a new generation? There is no inetOrgPerson for millennial developers to use. But does that even matter? We could take SCIM’s schema and decree it to be the standard. But we all know, that each of us would extend the hell out of it. Yes we started with a standard schema, but every service provider’s schema is nearly unique.
- Attributes’ wheel is more round than not
- This won’t be a diatribe against the sad magic of commas. I promise.
- We can access attributes… sorta.
- There’s no clear winner that is optimized for the modern web. We’ve got graph APIs, ADAP, and UserInfo Endpoints – not to mention proprietary APIs as well.
- If remove that constraint, then we could say that access to attributes is a fully solved problem: LDAP. But we are going to a protocol that enables workers in the modern web to access attributes.
- But we are going to a protocol that enables workers in the modern web to access attributes.
- As for a standardized representation… we have one. Name-value pairs. In fact, name-value pairs might be the new comma. (Ian speaks into cellphone “Siri, remind me to kill name-value pairs next year.) And although NVP are ubiquitous, we don’t have a standard schema. What is the inetOrgPerson of a new generation? There is no inetOrgPerson for millennial developers to use. But does that even matter? We could take SCIM’s schema and decree it to be the standard. But we all know, that each of us would extend the hell out of it. Yes we started with a standard schema, but every service provider’s schema is nearly unique.
- In fact, name-value pairs might be the new comma. (Ian speaks into cellphone “Siri, remind me to kill name-value pairs next year.)
- We could take SCIM’s schema and decree it to be the standard. But we all know, that each of us would extend the hell out of it. Yes we started with a standard schema, but every service provider’s schema is nearly unique.
- Attributes’ wheel is roundish
- User provisioning is on the verge to being semi-inflated. Let’s face it the wheel that SPML v2 built was not round. The example that the standard provided wasn’t even valid XML – not an auspicious start. In fact, SPML was a set away from roundness when we think about DSML v2. DSML v2 was a round wheel. It wouldn’t be very useful to day but it would roll. So what about SCIM? I’m bullish on it. Some really smart people worked on it, including my boss. We are supporting it. We hope you support it too. In fact, hopefully, at the end of this week it might just get ratified at the IETF meeting in Toronto. SCIM definitely needs more miles on the road, but I believe that the use cases that have been used to form SCIM are fairly representative of a majority of use cases we have. It can’t do everything but better believe it can do something. And this narrow focus is important as we think about the work we must do. As we as an industry shift from just dealing with employee identities to those of customers, citizens, and things, there is shift from heavy rich user provisioning to lighter weight registration and profile management. SCIM is just as applicable in an employee identity scenario as it is in a customer identity scenario. And thus is well positioned to make the transition.
- User Provisioning’s wheel is nearly roundish.
- Let’s face it the wheel that SPML v2 built was not round. The example that the standard provided wasn’t even valid XML – not an auspicious start. In fact, SPML was a step away from roundness when we think about DSML v2. DSML v2 was a round wheel. It wouldn’t be very useful to day but it would roll.
- So what about SCIM? I’m bullish on it. Holds great promise. Some really smart people worked on it, including my boss. We are supporting it. We hope you support it too. In fact, hopefully, at the end of this week it might just get ratified at the IETF meeting in Toronto. SCIM definitely needs more miles on the road, but I believe that the use cases that have been used to form SCIM are fairly representative of a majority of use cases we have. It can’t do everything but better believe it can do something. And this narrow focus is important as we think about the work we must do. As we as an industry shift from just dealing with employee identities to those of customers, citizens, and things, there is shift from heavy rich user provisioning to lighter weight registration and profile management. SCIM is just as applicable in an employee identity scenario as it is in a customer identity scenario. And thus is well positioned to make the transition.
- As we as an industry shift from just dealing with employee identities to those of customers, citizens, and things, there is shift from heavy rich user provisioning to lighter weight registration and profile management. SCIM is just as applicable in an employee identity scenario as it is in a customer identity scenario. And thus is well positioned to make the transition.
- User provisioning’s wheel is nearly roundish
- A question – how do you discover identity services of from a service provider? I don’t mean in a specific ODIC way, but in a more general way. How do you know if they use SAML, SCIM, a proprietary attribute API, FIDO U2F, etc? Is there a way to kickstart point-to-point identity relationships without paying the cost of point-to-point drudgery? Could I point my identity system at yours, form a relationship between the organizations, and start to use our joint identity services to meaningfully interact? Let me ask this a different way – do we have hubs and axels for our roundish wheels? Can we building something that removes the heavy lifting when offering and/or consuming identity services? I believe this is the uncharted standards territory into which we must blaze a trail.
- A question – how do you discover identity services of from a service provider? I don’t mean in a specific ODIC way, but in a more general way. How do you know if they use SAML, SCIM, a proprietary attribute API, FIDO U2F, etc? Is there a way to kickstart point-to-point identity relationships without paying the cost of point-to-point drudgery? Could I point my identity system at yours, form a relationship between the organizations, and start to use our joint identity services to meaningfully interact? Let me ask this a different way – do we have hubs and axels for our roundish wheels? Can we building something that removes the heavy lifting when offering and/or consuming identity services? I believe this is the uncharted standards territory into which we must blaze a trail.
- Can we kickstart point-to-point identity relationships without paying the p2p costs?
- Can we build something that removes the heavy lifting when offering and/or consuming identity services?
- That modern era is one in which more people and more things are more closely related. It is an era that holds the promise of “identity as business enabler.” And in this modern era identity will not only deliver the right access to the right people at the right time but the right experience to the right people at the right time. Not just people but things too To be fair, this modern era will require us to haul a heavy load. To do that we need round wheels. We need workable identity standards. We have made great progress but we are not there yet. I’ll ask 3 things of this audience and of our industry. First, adopt standards. If you aren’t using identity standards, you are inventing your own wheel. That is a strategy only optimized for the short-run. If the current ones don’t work for you, bring those use cases to standards bodies. If you don’t know where to go, ping me, or Mark, or Eve, we’ll help you. Second, help others adopt standards. Build SDKs to help people use OpenID and SAML. Support open source implementations of SCIM and OAuth. Start at home – with you organization’s developers and move out from there. Third, demand standards. From your identity technology providers. Demand standards. From your business service providers. Demand standards. From your own development teams. Demand standards. If for no other reason than to kill off the need for password vaulting. Demand standards. Lastly, keep in mind that a round wheel is not an end in and of itself. A great spec is potentially satisfying to the hard-core identity dorks in the room, me included, but that isn’t the real goal. We reinvent the wheel, we revisiting and rebuild our standards to get round ones – beautifully functioning ones that help carry the loads we must shoulder and us get to where we need to go in this era of modern identity.
- It used to be that enterprise IAM was concerned with answering did the right people get the right access. But that is increasingly not the relevant question. The question we must answer is did the right people get the right experience? IAM is in the midst of a transformation in order to serve customers, citizens, and even our “thing.”
- It used to be that enterprise IAM was concerned with answering did the right people get the right access. But that is increasingly not the relevant question. The question we must answer is did the right people get the right experience? IAM is in the midst of a transformation in order to serve customers, citizens, and even our “thing.”
- It used to be that enterprise IAM was concerned with answering did the right people get the right access. But that is increasingly not the relevant question. The question we must answer is did the right people get the right experience? IAM is in the midst of a transformation in order to serve customers, citizens, and even our “thing.”
- It used to be that enterprise IAM was concerned with answering did the right people get the right access. But that is increasingly not the relevant question. The question we must answer is did the right people get the right experience? IAM is in the midst of a transformation in order to serve customers, citizens, and even our “thing.”
- As we continue to refine our standards, we need a way of evaluating the roundness of those wheels, so to speak. We need some set of design considerations to help use decided whether a standard will get us from here to there. A few weeks ago I debuted the laws of relationships. They a set of considerations that we as identity professionals must be mindful of as we begin to navigate the waters of modern IAM – of identity relationship management. They can help evaluate the roundness of our standards… but only if you lend a hand. Kantara is creating an Identity Relationship Management working group to which I am giving these Laws of Relationships. I hope you will join me, and Joni, and Allan, and others in this new working group to help make identity ready for the modern era.
- Kantara is creating an Identity Relationship Management working group to which I am giving these Laws of Relationships.
- I hope you will join me, and Joni, and Allan, and others in this new working group to help make identity ready for the modern era.
- If you don’t know where to go, ping me, or Mark, or Eve, we’ll help you.
- Lastly, keep in mind that a round wheel is not an end in and of itself. A great spec is potentially satisfying to the hard-core identity dorks in the room, me included, but that isn’t the real goal. We reinvent the wheel, we revisiting and rebuild our standards to get round ones – beautifully functioning ones that help carry the loads we must shoulder and us get to where we need to go in this era of modern identity.
- at least to the hard core identity geeks in the room