I AM NOT MY PHONE - Avoiding Identity Relationship Pitfalls
•Download as PPTX, PDF•
0 likes•1,613 views
ANDREW JOHNSTON, Principal Technology Architect, TELUS, at the European IRM Summit 2014.
Recommended
More Related Content
What's hot
What's hot (12)
Viewers also liked
Viewers also liked (7)
Similar to I AM NOT MY PHONE - Avoiding Identity Relationship Pitfalls
Similar to I AM NOT MY PHONE - Avoiding Identity Relationship Pitfalls (20)
More from ForgeRock
More from ForgeRock (20)
Recently uploaded
Recently uploaded (20)
I AM NOT MY PHONE - Avoiding Identity Relationship Pitfalls
- 1. I am not my phone: Avoiding Identity Relationship Pitfalls Andrew Johnston Member of the TELUS Team
- 2. About TELUS British Columbia Alberta Manitoba Saskatchewan Ontario Quebec Atlantic Canada Canada has a population of 34.88 million. Network access lines 3.2 million TV subscribers 865,000 Wireless subscribers 7.9 million Internet subscribers 1.4 million
- 3. Pillars of Identity Relationship Management BUSINESS PILLARS 1. CONSUMERS AND THINGS over employees 2. ADAPTABLE over predictable 3. TOP LINE REVENUE over operating expense 4. VELOCITY over process TECHNICAL PILLARS 1. INTERNET SCALE over enterprise scale 2. DYNAMIC INTELLIGENCE over static intelligence 3. BORDERLESS over perimeter 4. MODULAR over monolithic https://kantarainitiative.org/irmpillars/
- 4. Identity is grounded in the data tier • Challenge: IRM encourages Adaptability, Velocity • Identity is primarily a data concern • Changes to the data tier are slow and expensive http://commons.wikimedia.org/wiki/File:Banaue_Rice_Terrace_Close_Up.jpg Data architects are your friends
- 5. Users are people, too • Business model vs. service model • Favour relationships over attributes • Born with it? Photo by Maurizio Pesce https://www.flickr.com/photos/pestoverde/
- 6. Things • Intrinsic properties of things • Things as credentials • Things as service providers Photo by A.cilia, Wikimedia Commons
- 7. individual customer service resource Relationships Photo courtesy of pixabay.com
- 8. Authenticating people • “Passwords have reached the end of their useful life.” • Credential Service Provider? • Credentials have relationships to a person Photo by Ranjithsiji, Wikimedia Commons - http://commons.wikimedia.org/wiki/User:Ranjithsiji
- 9. How do you know that? • Who told you that? • When did they tell you that? • Would there be any advantage to them to misrepresent the truth? Sculpture by Donald Lipski, 1985; Copyright: Donald Lipski. Photo: Dorothy Zeidman
- 10. Process and Controls • Use data and relationships for authorization • Measure and control data quality • Minimize data collection and distribution Photo by Lynn Betts, USDA Natural Resources Conservation Service
- 11. Be bold, but not reckless, on a path to the IRM future • Data architects are your friends • What data distinguishes you from others? • Everything should have (or be) an API
- 12. andrew.johnston@telus.com © 2014 TELUS Communications Company 12
Editor's Notes
- Hi, I'm Andrew Johnston; I work on Identity and APIs in the office of the CTO at TELUS. I hope today to leave you with some ideas for how to avoid potential pitfalls as you evolve your identity capabilities. Please feel free to interrupt me with any questions you have during the presentation. I’d also be happy to take your questions at the end.
- TELUS is Canada’s fastest-growing national telecommunications company, with 13.4 million customer connections, including 7.9 million wireless subscribers, 3.2 million wireline network access lines, 1.4 million Internet subscribers and 865,000 TELUS TV customers. TELUS provides a wide range of communications products and services, including wireless, data, Internet protocol (IP), voice, television, entertainment and video, and is Canada's largest healthcare IT provider. In support of our philosophy to give where we live, TELUS, our team members and retirees have contributed hundreds of millions of dollars to charitable and not-for-profit organizations and volunteered million hours of service to local communities since 2000. TELUS was honoured to be named the most outstanding philanthropic corporation globally for 2010 by the Association of Fundraising Professionals, becoming the first Canadian company to receive this prestigious international recognition.
- The challenge that identity in general, and Identity Relationship Management in particular, sets before is the establishment of an identity system, or a set of identity services, that are Adaptable and that we can evolve with Velocity. The challenge stems from two important facts: Identity is primarily a data concern. This data is used for authentication, authorization and personalization. There's a fair helping of security mixed in there, but if your data isn't properly organized and supported by good processes, you won't be delivering good security or customer experience. As experience with multi-tiered architecture has shown us, the data tier is the hardest to change. It impacts all the other tiers in our architecture. Significant changes can require data-conversion or data-migration efforts. Any system that depends on the data that's changing requires comprehensive re-testing at a minimum. In cases when the data might impact on customer privacy or security, you may also need to talk to all of your customers. You might need to ask them all skill-testing questions, or get them all to provide some new consent, or negotiate a new credential with them all. Customers may see this as the act of a concerned and responsible service provider, but they're more likely to see this as an annoying inconvenience. I recommend working with a good data architect. I'm not a data architect, but I've had the opportunity to work with some great ones. I've seen good data architecture decisions continue to pay dividends for more than a decade, while customer-facing applications have been replaced 3 times to keep up with technology and customer expectations. Image: http://commons.wikimedia.org/wiki/File:Banaue_Rice_Terrace_Close_Up.jpg
- You should know if and how and where the idea of "person" fits into your business and service models. In a business model, there are almost always people. Someone orders a service. Someone is invoiced for a service. Strength of identity assurance may not need to be high, but it's unusual to do business without people. For service models, involvement of people is common, but less essential. The delivery of liquid natural gas to a home, for example, doesn't require any human involvement once the service has been provisioned. Donald Knuth wrote that "premature optimization is the root of all evil." Don't optimize entities and relationships away too early in the interest of having a representation that fits neatly into, say, a hierarchical model supported by directory servers. It's better to optimize this later, once you have a better handle on what you might be trading off for simplicity or performance. If you are in doubt about documenting a new relationship vs. defining a new "person" attribute, ask yourself if people are born with the attribute. Was I born with a mobile phone number? Image: http://www.flickr.com/photos/pestoverde/15051962555 by Maurizio Pesce https://www.flickr.com/photos/pestoverde/
- If you are looking to the Internet of Things as part of your service, consider how those things might fit in your model. I think it will be rare to have to consider intrinsic properties of things as part the delivery of a service. As the Internet benefitted from the abstraction and standardization of the protocols and formats of the web, the Internet of Things will establish standards and protocols to make itself more generally useful. Providers of IoT services and applications may need to get into the details, but most others won't. One key exception to this is likely to be for things that your service uses as tokens of authentication. By looking to things as a "something you have" authentication factor, you'll need to get involved in the details for each of the things that will become part of your authentication story. This could involve enrolling device serial numbers, MAC addresses, network service identifiers and even network addresses in tightly controlled environments. These things will have their own lifecycles that need to be managed and controlled. Plan to model things separately, with their own attributes. It would be much easier to consider things as providers of services. Your system may rely on an IoT service provider to deliver temperature, or location information from one or many things. The service provider can worry about concerns like battery life, radio range, power and interference or hardware failures. Image: http://commons.wikimedia.org/wiki/File:Htcpcp_teapot.jpg Photo by A.cilia, Wikimedia Commons
- --> individual --> customer <--> service <-- resource Whenever I'm thinking about a new service, I find this mnemonic very helpful. Start with any concern, and consider whether a single example might have a relationship with one or more of any of the other concerns; then consider whether any of those concerns might share a single example, or relate to many. The "resource" concern is exclusively part of the service model, I think. Just as "customer" is exclusively part of the business model. All the concerns are likely to have direct or indirect relationships with one another. For example, we might ask whether a person could represent more than one customer. Then we would ask whether a customer might be represented by more than one person. To consider the example in the title of this talk, assume that a phone number is a resource that is only ever used by one instance of the mobile-phone service. Could a person have more than one mobile-phone service? Of course! Could more than one person share a single mobile-phone service? It's certainly possible. Regardless of the answers, the mnemonic has helped us recognize that I am not my phone. * It's useful at this point to remember that time is the great disruptor of beautiful models. Ownership of resources will change over time. Resources may be assigned to different services. Individuals will stop representing certain customers, and start representing others.
- A few words on authentication. This quote from Bruce Schneier is from February, 2005. Please do everything you reasonably can not to give your customers a new password. If you must issue your own credentials, consider combining it with a second authentication factor, so you don't need to impose arbitrarily difficult password format rules. A simple 4-digit PIN with a second authentication factor, such as proof of possession of a mobile device. Another approach to consider would be to rely on a Credential Service Provider to authenticate your end-users. If authentication isn't a core part of your service, look into the services offered by those for whom it is. This could be as simple as letting your users log in to your web site with Facebook or Google. If you're going to worry about end-user credentials at all, I suggest modeling credentials as separate entities that might have a relationship with a person. This allows for the possibility that your users may use a number of different kinds of credentials; that the credentials you choose to recognize and honour may change over time; and that there may be different circumstances that require the authentication of different credentials. High-value transactions, for example, may require the use of a stronger credential, or an additional credential type. It might be worth thinking of an authentication assertion from a Credential Service Provider as a logically distinct credential. Reference: - The Curse of the Secret Question - https://www.schneier.com/blog/archives/2005/02/the_curse_of_th.html Image: http://commons.wikimedia.org/wiki/File:Pendrive_Shape_of_key.JPG Photo by Ranjithsiji, Wikimedia Commons - http://commons.wikimedia.org/wiki/User:Ranjithsiji
- Cite birthday example. This kind of information is useful for actively or retroactively mitigating risk (access control, authorization, credential integrity, ...). Image: http://en.wikipedia.org/wiki/File:The_Book_of_Knowledge_%28Lipski_sculpture%29.jpg Sculpture by Donald Lipski, 1985; Copyright: Donald Lipski. Photo: Dorothy Zeidman.
- Authorization at scale can simply rely on your service model relationships For large-scale, consider a simple, static authorization model based on these relationships Integrity - enforce constraints at the data tier, save yourself huge grief - some day, what you create now will become legacy - decide on a "minimal" profile; what defines the entity? What is truly unique? (frequently this is artificial and assigned) - who is the (single!) authority for uniqueness? - domain names --> ICANN - email addresses --> service provider + ICANN - PKI subject --> Cert. Authority data minimization as a security and privacy strategy - "Person" entity with as few attributes as possible - "There are two kinds of companies. Thost that know they have been breached, ..." - point of contrast between CRM and IRM (?) - impulse to collect and hoard data - if you want to play with data, look at - web analytics - transaction analytics - fall-out analytics (phone call, customer ticket, etc.) -> measure that! Image: http://commons.wikimedia.org/wiki/File:TerracesBuffers.JPG Photo by Lynn Betts, USDA Natural Resources Conservation Service
- Thank you for your attention. Questions?