Cloud and Software Architecture, Soft skills, IOT and embedded
Identity Management - Internal, Customers and Partners
Get link
Facebook
Twitter
Pinterest
Email
Other Apps
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.
I do a lot of my development and configuration via ssh into my Raspberry Pi Zero over the RNDIS connection. Some models of the Raspberry PIs can be configured with gadget drivers that let the Raspberry pi emulate different devices when plugged into computers via USB. My favorite gadget is the network profile that makes a Raspberry Pi look like an RNDIS-attached network device. All types of network services travel over an RNDIS device without knowing it is a USB hardware connection. A Raspberry Pi shows up as a Remote NDIS (RNDIS) device when you plug the Pi into a PC or Mac via a USB cable. The gadget in the Windows Device Manager picture shows this RNDIS Gadget connectivity between a Windows machine and a Raspberry Pi. The Problem Windows 11 and Windows 10 no longer auto-installs the RNDIS driver that makes magic happen. Windows recognizes that the Raspberry Pi is some type of generic USB COM device. Manually running W indows Update or Update Driver does not install the RNDI
The Windows Subsystem for Linux operates as a virtual machine that can dynamically grow the amount of RAM to a maximum set at startup time. Microsoft sets a default maximum RAM available to 50% of the physical memory and a swap-space that is 1/4 of the maximum WSL RAM. You can scale those numbers up or down to allocate more or less RAM to the Linux instance. The first drawing shows the default WSL memory and swap space sizing. The images below show a developer machine that is running a dev environment in WSL2 and Docker Desktop. Docker Desktop has two of its own WSL modules that need to be accounted for. You can see that the memory would actually be oversubscribed, 3 x 50% if every VM used its maximum memory. The actual amount of memory used is significantly smaller allowing every piece to fit. Click to Enlarge The second drawing shows the memory allocation on my 64GB laptop. WSL Linux defaults to a maximum RAM size of 5
The Apache Tika project provides a library capable of parsing and extracting data and meta data from over 1000 file types. Tika is available as a single jar file that can be included inside applications or as a deployable jar file that runs Tika as a standalone service. This blog describes deploying the Tika jar as an auto-scale service in Amazon AWS Elastic Beanstalk. I selected Elastic Beanstalk because it supports jar based deployments without any real Infrastructure configuration. Elastic Beanstalk auto-scale should take care of scaling up and down for for the number of requests you get. Tika parses documents and extracts their text completely in memory. Tika was deployed for this blog using EC2 t2.micro instances available in the AWS free tier. t2.micro VMs are 1GB which means that you are restricted in document complexity and size. You would size your instances appropriately for your largest documents. Preconditions An AWS account. AWS access id and secret key.
Comments
Post a Comment