Right Consumer

Every consumer type defined  is  distinguished  by  its  unique definition process.  In the Right  Strategy every definition process (provisioning) results  in unique parameters being placed in a credential  store.  

Examples of provisioning

Internal Users - these are the  employees  of an organization.  Provisioning/de-provisioning is  often a very difficult and risky  proposition.  The more complex  the technological landscape (applications, infrastructure, emails)  the  more difficult the task.  In enterprises this provisioning is usually handled either by a security admin group or by the  HR on-boarding process.  Many  organizations  have automated the process because manual  provisioning was too error prone.  De-provisioning has also been automated, but it  is still a huge risk in organizations.  (De-provisioning gets difficult as the user adds and removes accesses over time as orphaned accesses may get left behind).  

The Right Strategy approach  is  much  simpler.  No user gets direct access to a tool (it can be done but it  will complicate administration).  Every new tool would require finding the appropriate users.  Instead, the role is given access to the tools.  An  auditor  gets this  list of tools.  A call center rep gets their list.  As tools get added, they get added to the appropriate roles.  A user  at provisioning just  gets assigned an appropriate role(s) (attribute in the credential).  The primary  security policy verifies that the user  accessing the resource (tool) has the appropriate role.  This policy is expanded to verify that the requester satisfies the rest of the  tools access requirements (can complete the tool signature, has all the credential  parameters so the  tool will work.  

Tool Signature is  where  more stringent rules can be applied.  This is where a workitem (business  need) is applied.  The policy can enforce step up authentication by assigning an authentication level to the resource (when assigning  it to a role).  If the users active credential does not  meet the  required authentication  level, they  will be vetted appropriately  by the  security  policy.  The policy  does  this  the  same way  as  if the  user didn't have an active credential (require sign on). The example is that a user  may  require a security  token for certain accesses even after they are already signed on.

The approach above works for all user types that are enterprise administrative governance.  External partners (external customers that can access internal applications) can be given roles for access.  The business partner can even provision those users into the  roles but by  policies established by the enterprise.  This requires  the  enterprise  to "trust" the credential provided by  the partner. An example for this was a sister agency  that required  access to some of our information to process their own claims.  Instead of our agency creating and  provisioning users, we empowered the sister agency  to maintain their  own.  They could only provision the roles we provided. They used the same credential provider which  simplified the policy, however another credential service provided could have been satisfied by adding credential provider(s) to the  policy.

The approach for external customers required  self service.  Self service requires a vetting process to  get access.  The goal is to create a customer identity  for  conducting business.  A transaction can be the vetting.  After you make a purchase, they may ask you to create a user to follow your orders.  The provider already  has your information, so account creation is easy and somewhat low risk.

Digital relationships  get riskier  when the  consumer relationship has a  history  of transactions (many of which are non-digital) and there is a risk of identity theft.    Financial institutions, government, and healthcare are representative of enterprises with this situation.  The  goal is to allow self service, but the risk is high.  External customers can identify themselves through  some shared knowledge with the provider.  This can be very intensive and may  require the consumer to gather considerable information from "registering".  In today's internet, the provider would reqruire you to create a user id/password.  This is becasue they are being thought of as  silo.  You may be even able to federate by using another  of your signons (Google).  In an attribute based system, the provisioning the leaves the  attributes of the veting (customer id, accounts, etc.) in the credential store.  The  company does  not have to create a consumer  account.  

Similar vetting processes can be used to register businesses.  Many of these relationships are based on a long history and for many enterprises may, at least partially, be a manual process.   Self service business registration  has an additional level of complexity because the user (at this point in time there  is always a person) has to have a verifiable relationship  with the business that allows them to conduct  the  companies' e-business.  In the  Right Strategy the registrar for the  business is  empowered to administer  security  accesses on the  business' behalf. They can create users, grant accesses, and even create other administrators (who can perform security  administration functions for either the whole organization or just  a portion).  

Agents are a unique subset  of business and individual cases.  They  get vetted as to a "higher" level.  A hospital, doctor, lawyer, accountant get vetted by  accessing unique  sources that verify their administrative expertise.  For lawyer you may check the Bar Association (and even status - has the lawyer been dis-bared), for a doctor you may check the  AMA, for an accountant you may check their ability to electronically  file returns.   These representative types can then  be delegated to by  a registered business or individual.  The delegation can be bound by period (this tax year) or transaction type (a particular specialist may only view a subset of my  data).  Likewise health proxies and power of attorneys can follow the pattern.  The user now has the credential (parameters) vetted by their client.  At access the only difference is the user, the  detailed account parameters are the same.  

The Business (B2B) relationships are more formalized.  There is not only an agreement between the parties, but often there is co-development, testing, and integration.  The outcome is still a credential that has access to the service, but it is not  an individual's credential.  It is either the organization's credential or the organization's credential for a particular "application" (subset of services).  An example, when I was Deputy  CTO the state health exchange was being developed  by  an outside vendor.  As part of  their evaluating applications they needed to access sensitive resources at several agencies  (household income information from tax, records from health, information from labor, etc.).  We decided to do two things to limit  risk.  Give one single credential that was for the application that could be used across agencies (a health exchange credential) and the other was a single gateway to process the credential.  With any credential there is the potential for inappropriate use.  The outside vendor could have used (or its site could have used) the credential to access data independent of  business need (health exchange).  The  single credential allows for behavioral analytics to find inappropriate use (services called out of order).  Application level credentials, just like a tool credential, embodies business need into all capability access.

For completeness, IoT provisioning follows patterns similar to internal provisioning and application provisioning.  An IoT device may have multiple personas (similar to roles) that have different accesses.  They may be provisioned by different authorizers.  A car might have a certain persona (car health) that is provisioned by  the car company, there may be a different authroizer fo the  public safety persona, and the  car owner provision the comfort and entertainment personas.  For a large IoT engagement, the type of device can be provisioned like a role for a user.  

The commonality behind all this  is that any  vetting process creates metadata in the directory  that allows very fine grained access to  assets.