www oasisopen org Trust and Shared Identity Management

  • Slides: 12
Download presentation
www. oasis-open. org Trust and Shared Identity Management Across Company Borders Policies, Processes and

www. oasis-open. org Trust and Shared Identity Management Across Company Borders Policies, Processes and Agreement Issues to be Considered – A Case Study Markus Salo Concept Owner for Identity and Access Management Nokia Oyj

www. oasis-open. org Introduction In 2006, Nokia and Siemens decide to join their network

www. oasis-open. org Introduction In 2006, Nokia and Siemens decide to join their network functions. A new company, Nokia Siemens Networks (NSN), is founded for this purpose. In the beginning, the new company does not yet have the necessary IT infrastructure in place. To ensure viability of NSN, the parent companies have to chip in. One of the necessary IT infrastructure components is, of course, Identity and Access Management (IAM). Our story begins here….

In the beginning… n n n HR functions are the first to separate –

In the beginning… n n n HR functions are the first to separate – all former Nokia, former Siemens and new NSN people are consolidated to NSN HR. Former Nokia people disappear from Nokia HR, and thus from the ken of Nokia’s highly centralized Identity and Access Management (IAM) How to retain the identities and access rights of former Nokia workforce in Nokia systems until comparable NSN services are in place? How to create identities and access rights in Nokiacontrolled systems former Siemens, new NSN people if that is required?

Well, we have options… n Option 1 (straightforward) l l n Freeze the identities

Well, we have options… n Option 1 (straightforward) l l n Freeze the identities of former Nokia people to retain access rights Use normal collaboration processes former Siemens, new NSN people if they require access to Nokia-administered NSN systems not yet migrated to NSN control …but there are drawbacks… l l Identity information former Nokia people degrades quickly (terminations, significant attribute changes) Nobody left at Nokia has an interest in managing former Siemens, new NSN people n n Former Siemens, new NSN user volumes may become very high since it takes time to set up services in new company Applications have come to rely on highly centralized IAM so cannot migrate to NSN control until services are ready

…and other options… n Option 2 (more complicated) l Set up trust and identity

…and other options… n Option 2 (more complicated) l Set up trust and identity exchange between companies (mostly one-way) n n l Get identities former Nokia people directly from NSN – and this way, we’ll also get all the significant changes in real time Same mechanism can also be used to get identities former Siemens, new NSN people who require access to Nokia-administered systems Identity and authorizations approval authority is (mostly) delegated to NSN since there’s nobody at Nokia who has an interest in this on individual-user level

Guess what – we go to option 2! n Not without problems though (and

Guess what – we go to option 2! n Not without problems though (and this is only technical!) l l Id. M technology is not really geared for identity exchange on either side – but we muddle through, adapting existing systems Access methodologies do not really support massive use in cross-organizational environment n l It would have been wonderful to have a scalable, easily deployable federation solution available…again, we adapt existing methods IAM concept for trust and identity exchange is not ready on either side – we cobble it together as we go along (and this is partly to be blamed for the other problems we had)

We did get some things right… n n n We (correctly) assumed that usage

We did get some things right… n n n We (correctly) assumed that usage of Nokia-controlled systems by former Siemens, new NSN people would get very high – and designed technical solution to support this We delegated (most of the) identity and authorizations approval authority to NSN, since NSN is the only party with active interest on authorizing its individual users We designed and implemented policies to support trust and identity exchange We designed and implemented processes to support trust and identity exchange We even managed to harmonize credential spaces (partly anyway), anticipating increased integration needs

…but failed to consider others. n We did not check whether NSN had a

…but failed to consider others. n We did not check whether NSN had a supportable identity & authorizations approval process in place l n We did not verify identity exchange data quality l n Technical limitation, but rooted in the Id. M concept We were unable to define exactly the scope of services Nokia would provide to NSN l n Checks and filters were not in place, so we ended up getting flawed data, with imaginable consequences Nokia Id. M could not flawlessly support two separate identity sources l n What they had was not geared to the user volumes we were facing And were swamped with service requests that wildly exceeded what we thought was the scope We did not have a universally applicable authentication mechanism in place, so ended up adapting our existing systems

What’s to be learned from this? n If you choose to exercise this kind

What’s to be learned from this? n If you choose to exercise this kind of trust for collaborating with a partner… l Ensure that your partner is capable of handling the delegated identity and authorizations approval authority without your support n l l Review your security policies and, if necessary, change them to reflect the trust relationship Verify the quality of data you are receiving – in the end, you will be left holding the bag Have the technical Id. M capability to support a multi-organizational environment Define exactly what services you are providing to your partner – this must be stated in agreements n l Policies, processes and support systems must be in place On a technical level, having a workable RBAC solution may help… Ensure that you have an authentication and connectivity solution to address most access requirements n Again, federation may help as a technical solution

To put it all in context…. n n Note that the case described here

To put it all in context…. n n Note that the case described here is not one where a purely commercial service is provided by one company to another. In such situations, the scope of activities is severely circumscribed and more easily definable. Rather, this case describes partnership between companies, a situation where responsibility is harder to affix and the scope of activities may change at a moment’s notice .

Thank You!

Thank You!

www. oasis-open. org Speaker Bio Markus Salo began his Nokia career in 1997. From

www. oasis-open. org Speaker Bio Markus Salo began his Nokia career in 1997. From almost the very beginning, he became involved in Nokia Identity Management initiatives, and has worked in this area since. He has participated in numerous projects addressing Nokia internal and external identity and access management needs, particularly in his capacity as Identity Management architect. Markus is currently working as Concept Owner for Identity and Access Management, guiding the conceptual development of this field at Nokia. Contact Information: Email: markus. t. salo@nokia. com GSM: +358 50309 1872