The Right Strategy is a philosophy that leads to a consistent delivery of IT.  Consumption is simplified in the Right Strategy.  There are only two types of consumers those that use a tool and those that consume direct capabilities.  This simplification leads to certain universal foundation  patterns.  ATLaaS is  first pattern.  

By focusing on tool development, a group of integrated products can be delivered that can support business configuration, simplify and harden security, improve performance, and increase agility.  This collection of products is collectively called ATLaaS (Application Tooling Library as a Service).

ATLaaS is made up of several components

Everywhere on the web consumers have dozens  of user IDs and passwords.  Some vendors try  to simplify  this by becoming your id/password repository.  This simplifies consumer usage. It supports  federation at an id level and means any  resource security is  administered at the federated site.   It means that a vendor "owns" a great deal of your relationships and is a point of exposure.  

ATLaaS compliance takes the relationship further.  Instead of a vendor owning you, it defines a relationship where you  own your  credentials, their allocations, and the  vendor (CCV) consistently stewards secure, encrypted, detailed storage by consumer relationships  (the  other  web sites become RPs).  

The credentials  stored can be more  fined grained rather than just user id/password.  A CCV can support this, but it  is the most trivial relationship.  The password managers work this  way where the  URL can be thought of the  directory that owns the user id/password.  Is ity encrypted?  Probably.  Is the  directory  owner by the  URL owner?  No.  They can't de-provision.  That would only be found on  attempt  to  sign on to their  system.  The only  relationship to any URL (RP) is that its  user id/password process follows a certain standard for participation.  

Think about how you create an account at a site (URL).  Sometimes it  is  something the site offers on the landing  page before  you've done any action. They  get some very personal data (address, phone, email) and may  even give you some discount or other  benefit.  A user id and password is created.  Another way is at "checkout".  At the end of the  transaction  the site may give you an opportunity  to track you  transaction.  The same  personal data is captured, but  now the vendor  can use transactional  data to  enhance the account (the internal customer id).  Another way  to create the account is to do some vetting to get to the account details.  Your ISP, media companies, energy  providers, government all  follow patterns like this.  It is  the preferred way  if there is a prior relationship.  This  way the consumer's history can be related to the same account.  

In ATLaaS he goal is to externalize all credentials (CCV).  They are kept in a distinct directory that does not necessarily have to be Enterprise owned.  This allows many  implementations including hybrid models (one directory for internal employees, another for "customers").  For customers, the desired end state may be something generally available (Soverign Id) ora commercial offering.  The customer creates a unique id (user id, etc.), registers some minimal demographic data (that sharing  with  RPs can be controlled by policy).  Each  time a customer tries to access a detailed RP resource, the  credential metadata is evaluated.  If it doesn't exist for the entity  they  will be vetted so that the required complete credential can be satisfied.  The metadata  then get added to the credential store for subsequent accesses (based on policy).  The URL signature may  also require a certain level of authentication (it may  require two-factor or bio-metric) which is enforced at this time (IdP functionality).  This  just  in time credentialing contextualizes the vetting process.  It should be pointed out  that ATLaaS believes in just-enough identity.  (If someone would rather have two separate IDs that is up to the consumer.  They are willing to give up ease of use for a sense of "security".  In my experience we allowed people to register at both Tax and DMV.  Some choose to have two different IDs.  The question was - is our goal identity  or enabling customer service?).

For internal customers, partners, and IoT an existing directory may  be used.  The difference is that security  is not self-serve.  There are groups of people whose job it is  to administer security.  Users are manually  created (may  be tied to HR). Authorizations can be part of onboarding (roles), but  as career and business needs change authorizations will have to be altered.  This  is not simply a change, but  an entire process of validating the change and getting appropriate approval.  ATLaaS can change the  process here.  It can empower distributed role management.  Roles can be owned by  different business units (Auditors are in Audit).  If someone wants or thinks they need to have another units authorizations they  can request it (not having access is another example of an incomplete credential and the  request  can be made).  This gives  the  Enterprise flexibility  to use staff as needed, not necessarily how "organized".  If someone given access is doing something they  shouldn't do you have a security  issue or a management issue?  (ATLaaS  tracking will  be  discussed later). 

There is only one type of access in ATLaaS.  It is just a call to a tool (or simple tool service).  When a tool is composed, it  consolidates capabilities from many  sources,  Each source is  a relying party.  The tool framework passes to that capability credentials stored at vetting (customer id).  The tool signature is the  super set of all credential details needed for the tool. If the CCV doesn't have some needed credential metadata, it can leverage the  RP for the missing metadata.  This  is very similar to step up  authentication, it is real time vetting depending on the tool accessed.  

All resources require  credentials encapsulating the tool  metadata.  And all that  data is  stored in CCV via RP vetting. This  single pattern is coordinated by the ATLaaS Controller.

With the goal of empowering consumers to own their internet "lives" setting up  a universal way  to control credentials is essential. One often ignored pattern is that of delegation.  It  is common for consumers to require others to  access their assets in pursuit of an outcome for the consumer. Lawyers, health proxies, accountants are just some examples.  Today a representative is given the information they  need and the consumer loses all visibility to how it is used.  The health proxy gets access to your health record and its usage (how often, what for) is lost.   The  consumer usually  has  a portal for each provider where they  can access data and may be able to "delegate" access to their representative. 

Since tools are written with  a tool signature, delegation  is just giving your signature (metadata) to another.  They access the same (or similar) tools  as the  consumer, just with a different "user".  

Some delegates required additional vetting.  A lawyer  must register as a lawyer (maybe vetted by  the  Bar Association), Accountants may  register with  their federally acquired ETIN.  This registration may be on an organizational level where they can delegate to their organizationally  maintained users.  The delegation is always controlled by  the  credential holder.  It can be a request for access by a delegate or using the ATLasS Portal to perform all delegations.  (The portal allows search of all registered delegates for allocation).  

 ATLaas Registration is offering a product through the portal (or services).  An ATLaaS resource is a certain type of product.  It has the description above (URL, Metadata, etc. in a commerce site product, size, color, etc.)).  For each piece of the  required credential (metadata) it establishes the needed RP asset to perform vetting.  The signature may also require other metadata (order number) which needs to be acquired prior to execution.  The registration describes the "purchase contract".  It defines that on subscription what process will be followed - what business case, await approval, immediate access (with notification), policy and terms and conditions, customer base (busines, individuals), testing requirements, usage limitations and costs, delegate-able, to what group  of consumers, can be delegated to, etc.  The owner of the assets sets the  rules.

The subscriber can view all assets registered (they  will be listed as ATLaaS services and may  be just services or UI components).  This  is essentially  an AI enhanced search of assets.  They will then follow the established policy for subscription (purchase contract).  This may  include  approvals, testing, and financial agreements.  The assets that require  a business case may give the  subscriber special credetnatials to maintain context. (I once had to give access to sensitive data based on another agency very  specific legislative needs.  They were given a special credential and their access were monitored for behavioral consistency.  If they were found in violation, their  credentials would have been invalidated). A subscriber may define an ATLaaS Adapter to be used during fulfilment of  this  contract.  The  ATLaaS Adapter is the subscribers integration point to their  tools.  

Upon successful purchase, the policy  will be deployed  to the ATLaaS Execution environment.  The delegation runs  under the initial subscription.

The single execution environment allows for very detailed tracking of all accesses.  This tracking is enhanced from current solutions because  it has context.  It knows the problem that was being solved (it knows the tool). It knows who was using it and in what context (the metadata like customer or work id).  Why  did the customer rep access my account?  Because he was solving an account issue (work item).  

ATLaaS tracking exposes the  real-time customer journey (navigation within  tool capabilities) and supplies an integrated audit trail.  It was used to verify  "drop off" rates of complex external facing apps (tool improvement), for managers to monitor employee work (are they  doing the right  things based on priorities), to understand the  volume and transactional diversity of transactions, to evaluate capability delays and issues, and to expose opportunities for improvement.  The contextual journey  streams were analyzed with outcomes and other success factors, to improve the tools and training. 

ATLaaS Execution follows a similar pattern to many  existing security  protocols.  It differs primarily in the tighter integration with relying parties and contextual credentials.