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

    Comments

    Popular posts from this blog

    Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

    Understanding your WSL2 RAM and swap - Changing the default 50%-25%

    Almost PaaS Document Parsing with Tika and AWS Elastic Beanstalk