Federation For The Cloud Opportunities For A Single Identity

Editor's Notes

• #4: A typical user has very big problem, without even realising it. Multitude of internet services require users to create “new account” and repeat the registration process all over again. This bring two problems:Multiple accounts to managePassword problemLet’s start with the first one. When I looked into my 1Password database this morning I counted 380 credential details for various websites and further 50 accounts for non web based services. It is truly incredible number and without the help of a password manager software I could not manage this exposition of accounts. That leads me us to the second problem – passwords, still, only supported authentication by most websites. Recent studies and security incidents have confirmed our suspicion: that people choose simple passwords and share it across many systems. This is not only problem for those users but also for companies. I will come to that later.Sheer number of various website guarantees that people will not use unique passwords and those password are unlikely to be anything considered strong. I believe people have desire to use one identity system across many resources and it is up to us, security professionals, business, service providers and also governments to come up with a usable system. The generation Y has shown us that bringing personal internet experiences and ways of working to business is inevitable. Many businesses banned Facebook few year ago, while many business now are allowing social networks to thrive amongst their employees. Times are changing. Inevitably we will be facing questions from new employees, such as “I want to use my Facebook, Google, Live ID to sign in to the network… What, it is not possible. You are so 2011.”
• #5: I tried to illustrate some of the most popular websites on my password keying. I cannot reuse my credentials across any of them. Let’s now go to the business side of the problems.
• #6: Business face even bigger challenges related to identities. The number of internal applications in business tends to rise with the size of the company. And if the businesses are not careful and operate good project and architecture governance, many of these applications might implement their own authentication and authorisation capabilities. The matter is also not helped by software vendors that, sometimes, require specific Idm system implementation in order for their application/system to operate correctly or even with a warranty.In the end an organisation may have a few IAM systems (AD, LDAP (many variations), Kerberos, PKI (many implementations)) which further confuses both company users and projects.Building on this complexity, companies also want to do business with 3rd parties. These trusted partners, trusted limited by the contract signed, need to access company resources (data and systems). The policy has always been that 3rd party users must have their named accounts created in the 1st party IAM systems. This brings a raft of challenge, such as managing the flow of the information about leavers and joiners between two companies; so my company can disable the accounts for users in your company. In effect I do not trust your company to manage your users properly, so I’d rather do it myself and control the process. In many cases this approach leads to ghost accounts of 3rd party users that still have access to my system, yet they have long left the 32rd party company.Final piece I the puzzle is the Cloud. The problem with cloud and identities in business is similar to the problems in the personal space. Unless the cloud provider and the business can agree and support compatible IAM architecture, the business users will need to use yet another credentials to access the cloud provide services. This is especially problem in SME sector, very same sector that is most likely to actually use Cloud services.However, on the other and, there is genuinely lack of a good trust assurance model that companies could use easily, scaled to their needs and most importantly agreeable by all parties.
• #7: In this example the corporate user uses his personal device to access company applications. Just ignore the location of the user, intranet, internet for now. The company has one or many IAM platforms (pictures on the left). In many organisations this is Active directory also used to authenticate users to their computers. Now there are numerous applications available to the user. Again, ignore the location of the systems an the access path. In the example here, there on odd application that is not hooked into the company IAM system. Hence the user has to remember another set of credentials. These credential, usually set by user, are likely to be exactly the same as with in the company IAM system, obviously for convenience reasons. What that means to company risk profile? The company has spend considerable amount of money building secure IAM platform. Yet there is an odd system that potentially has not gone through the same security architecture and review process and this system is storing exactly same password for the user. I hope you see the point here. Your IAM platform is as weak as the weakest application that is not using your IAM platform.The lessons learned from this example is: build usable, extendable and secure IAM platform and push very hard to hook all company systems into it!
• #8: Building on the example from the previous slide, this time we add 3rd party to the mix. The business has linked all internal systems with the company’s IAM platform. Great. Now there are 3rd party systems that need to be accessed. Same problems arise, if even one 3rd party application is not using user’s company’s IAM platform. The situation is even less clear as there potentially little visibility about security controls within the 3rd party application (second from the left).The problem is even is exaggerated by the fact that the likelihood of compatible IAM solution on provider and user side is obviously lower then if discussing just systems within one organisation. The provisioning of the accounts on the 3rd party side is also an issue to be resolved. Even if the organisations have compatible IAM platforms and can so SSO between them, the account provisioning is usually done by a batch process.And, as discussed before 3rd parties may also want to access internal resources in your organisation. Most organisations simply create internal accounts for these users, which brings several management and risk challenges.
• #9: Finally, with the Cloud services fully on the radar or company CIOs the issue of 3rd parties is replicated with the cloud providers. In effect some 3rd parties could be classed as Cloud providers actually. Here, the problem of reused passwords is even bigger as many cloud based services (especially SaaS) do allow acess from anywhere on the internet. Hence, if a username and password is compromised your organisation has little control over who actually accesses the cloud application. Some cloud providers provide additional controls and can limit IP ranges that can login to the application – effectively linking information from the network layer with the application layer.
• #10: Let’s now summarise the challenges that businesses face in IAM space:Unless all internal systems in the company network do utilise services of the internal IAM platform, the risk of credential compromise though leakage in these systems needs to managed. This in essence is a usually unaccounted for element in the business cases for common IAM platform. Accessing cloud services and making sure the access control is fit for purpose is a problem organisations need to face. The standards are evolving and not all cloud providers offer federation and SSO services.Outsourcing services to 3rd parties face exactly the same challenges though the likelihood of tailored solution with 3rd party is higher.If 3rdparties needs to access your company internal resources, the cost of management of their internal accounts is usually higher thnafor internal users. Also, the out of sync issues are hard to resolve. Companies are also cautious to trust 3rd party to manage their IAM processes. Companies will be tested on how they adapt their identity capabilities when it comes to the personal space – that is both employees accessing company resources and customers accessing your business services. As new models for identity assurance emerge (more on that later) companies will be forced by market forces to adapt these new frameworks.
• #11: Recent NSTIC (NATIONAL STRATEGY FOR TRUSTED IDENTITIES IN CYBERSPACE) vision document shows the way forward where an identity ecosystem framework is created. Such a vision will require a lot of work both on the technology and also policies and processes side. Ultimately the decision needs to be give to people of what identity attributes are shared with the service provider, while the service provider needs to have reasonable (required) level of assurance that the identity provided is actually as stated. collection of trusted accredited identity providers issue
• #14: Point out different standards for getting physical identity, this is likely to be replicated to eID. Especially if those physical documents are used to obtain the eID.I personally use the eID to digitally sign the documents. However cannot use it to gain access to websites.