Identity Management - Internal, Customers and Partners

Companies often manage multiple identity pools, Internal users, B2C customers, B2B customers, Partner interactive and, Partner M2M.  Internal, Customer, and Partners often use completely different systems for identity management, authentication AuthN, and authorization AuthZ.  Their automation and identity controls are different even when their security risk profile is the same. The different user types have similar requirements but we often implement them separately.

User types are often implemented and managed differently even though they should have the same top-level compliance and security requirements. Identity systems all need to provide some basic functions.

• Identity Persistence
• Identity Creation and Deletion
• Identity Validation
• API and integration points for systems and applications.
• Group and role manipulation
• Group and role exposure.
• Self-management via API or Console
• Automation integration points for identity and permission manipulations
• Governance and compliance
• Others I'll remember in the future

Click to enlarge

Video

Identity Pools

We have three main types of identities, customers, partners, and internal. They often have their own identity stores, role management, access control policies, and implementations. 

Customers are often islands to themselves.  They basically exist on their own with no true relationship to others.  The customer/consumer ID system is a single domain or domainless. Internal users belong to a single managed domain. The internal ID system is a single domain.  Partners each exist within their own corporate domains for management and access purposes.  The partner system can be standalone or it can truly integrate with partner domains for authentication and/or roles.

Internal users

Internal users are employees and contractors that work for the company. They often have their own applications that let them work across users and lines of business.
Companies generally have a central identity management system containing their entire identity. Internal applications base security on combinations of business rules and role assignments that exist in the identity management system. The company adds or removes roles based on changing job roles. Larger or more regulated organizations often have very explicit identity onboarding, offboarding, and permission provisioning processes. Applications and systems must integrate with Identity and Role systems like Active Directory and with authentication systems like Ping, Okta, Cisco. Smaller companies may have an Active Directory with a manual process for creating accounts/identities and managing role permissions.
Most people are familiar with this because they interact with it every day.

Customers - B2C

Customer accounts exist for the customers to work only on their own behalf. They tend to use optimized applications or websites that are targeted at a customer doing work for themselves.  There generally is no OBO concept.  Customer account recovery is often bound to digital devices or electronic addresses. 

The simplest customer model is that of unlinked people where each login is bound to a single person and a single account.  This is the model initially used for all social media companies and internet shopping sites.  

Banking and other sites support linking business accounts to multiple individuals based on their legal linkage.  This is really giving individuals access to their own resources, each as if they were the only owner of that resource. Those linkages are at the contractual level and don't represent an organization. Identities bound to accounts may come from any number of domains or organizations.

Familial linkage is often the next level up from the single-level accounts. Accounts for minors are given limited access to a shared resource like digital movies or video games. The master account manages who is part of the family.  Systems that were built with the simple 1:1 model mentioned above often struggle to implement an integrated familial linkage. User accounts are often bound to email domain logins and may come from any number of domains.

Summary

Category	Individual	Contract Linked	Family
Identity Provider	Self or Social SSO	Self or Social SSO	Self or Social SSO
Administrator	None - Minor	None - Minor	Minor Preferences
Domain	No Domain	No Domain	No Domain
Permissions	Business Rule Driven	Business Rule Driven	Parent Admin
Multi-Account	Soft-Linking	Contact Based	Not Supported
Modernization	MFA	MFA	MFA

Customers - B2B

B2B customer identities are managed similarly to partners. Organizations and not individuals are the external party in both cases.

Partners - Users

The simplest partner system is one managed on behalf of the partners.  The hosting company adds and removes users based on requests. It assigns roles based on requests. There is no multi-domain support.  This is similar to B2C customer identity management with the added risk of permission management. Manual processes with their own cost and risks.  A user may be live left live in a system after they have left the partner because someone forgot to manually disable their account.  

A self-service console is an option that is managed by Partner designated administrators.  This is often the system of choice for small partners. Those administrators manage identities and role assignments or permissions.  The partner holds the liability for protecting their accounts and for tracking hires, terminations, and job changes.  

Account federation is probably the best option when it comes to enterprises. They can use their internal systems to manage accounts and their roles.  The first level integration is account identity. The second level integration is permission integration.  Smaller companies may not be able to support either of these.

Partners M2M

Machine-to-machine communication is where a partner's software processes reach into your software processes. These processes come with their own identity and credential challenges.

A lot of Partner M2M is handled via manual processes.  Partner M2M identities are not changed very often. Secret rotation tends to be relatively rare.  Partners often have primitive secret handling and may have forgotten how they integrated credentials "a few years ago".  No one takes ownership of the account and forgets about them. Some partners share several, or many, sets of credentials when they have multiple interaction points.

Partner systems should have a self-admin capability where a team can enable/disable or request credentials.  This normally involves one or more accounts having delegated administrative privileges to manipulate their own company's credentials.

Pushing credentials and roles from the partner company into a hosted, shadow, identity store is probably the best most option for most companies.  This lets the partner manage credentials and roles on their side and replicate those into a partner identity store.

Cloud providers can provide partner identity services. Generally, those can be created via manual or automated processes.  Some cloud providers can create cross-company trust relationships and manage permissions on cloud resources.  This a topic for another time.

Summary

Category	Interactive Small Company	Interactive Enterprise	Integrated Partner	Embed M2M
Identity Provider	Partner Platform or Social	Partner Platform or Self	Internal or SSO	Platform
Admin-istrator	Partner Platform	Partner Platform or Federation	Tech Team	Tech
Domain	Partner Platform	Federation	Internal	none
Domain Count	Virtual	Many	Few	One
Permission Mgt	Automatic Assignment	Self Admin or Federation	Internal	Manual
Modern- ization	MFA, self-service	MFA, self-service SSO	MFA, self - service SSO	Federate Cloud

Filling in more Details

Click to enlarge

Created 2021 12