Child pages
  • File Lists

Authentication Assurance – AAL

Also termed AuthN

NIST LEVELS 1-3

1 – some confidence that the person using it is who they say they are (UN/PW)

2 – more confidence that the person using it is who they say they are (MFA)

  • OTP
  • Yubikey

3- Highest confidence

  • proof of possession of a key through a cryptographic protocol.
  • AAL3 authentication SHALL use a hardware-based authenticator and an authenticator that provides verifier impersonation resistance

 

What provides “confidence” – a long list of requirements including: the strength of binding, the inability to spoof, deter MitM

 

A screenshot of a cell phone

Description automatically generated

A screenshot of a cell phone

Description automatically generated

 

 

Authorization –

AuthZ - The right to do something, consent, permission

 

Authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to or what they can and cannot do

 

NIST does not define levels of assurance around the concept of Authorization

 

Often the two concepts go hand in hand…a person first authenticates themselves to their customer facing portal and then authorizes a transaction.  “ Does AAL imply that that any resulting Authorization is also equally strong ?”

 

What is in use today for AuthZ:

OAuth Framework - OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.

 

However, OAuth 2.0 has limitations:

1)     Doesn’t support detailed context about the request

2)     Needs to be fine grained – ability to easily add/enforce step up AuthZ, ability to allow/disallow ability to provide consent based on changing conditions.

3)     Security – Token leakage and injection

injection threat comes from the fact that client cannot assume that only the resource owner can present it with a valid access token for the resource. Therefore, an adversary can easily inject the leaked or stolen access token (and impersonate the resource owner) when client accepts access tokens from sources other than the return call from the token endpoint. That happens when client uses an implicit flow.

 

 

On-deck for OAuth:

CONTEXT – Rich Authorization Request (RAR)

Fine-grained permissions during an authorization request. For example, an app may specify a request such as "let me make a payment of 45 Euros" or "please give me read access to folder X and write access to folder Y".

 

Other Industry Sectors and Use Cases

 

PSD2 = Revised Payment Services Directive is an EU Directive, administered by the European Commission to regulate payment services and payment service providers throughout the European Union and European Economic Area.  

 

SCA = Strong Customer Authentication The requirement ensures that electronic payments are performed with   multi-factor authentication , to increase the security of electronic payments. [1]   Physical card transactions already commonly have what could be termed strong customer authentication in the EU ( Chip and PIN ), but this has not generally been true for Internet transactions across the EU prior to the implementation of the requirement, [1]   and many contactless card payments do not use a second authentication factor.  

 

Open Banking and Healthcare – Ability for the patient to involve 3 rd parties of their choosing to receive/maintain their PHI and perform transactions on their behalf.  (OPEN HEALTH)

-          Patient’s right and ability to have access to their own medical data

-          Open APIs made available by the EMRs are used to facilitate this access

-          Tech companies have already solved the data sharing problem using two protocols to delegate access to sensitive information: OAuth and OpenID Connect. These protocols provide protection of APIs that hold sensitive user information. They make sure that the person who is logging in has permission to access the information, and that they have been properly authenticated.

 

 

 

Next Generation of Authorization Specs

 

Transactional Authorization (TXAuthZ)

XYZ AuthZ

XYZ has several core features that drive its design principles, and these are key to providing a consistent data model:

  • Intent registration. This allows the client to start the process off the same way every time by doing   request to the authorization server .
  • Don't assume the user has a browser. Interaction needs to happen in a   variety of ways depending on the capabilities of the client , and only sometimes will a browser be involved.
  • Minimize the front channel. When a browser   is involved , the protocol seeks to minimize the amount and kind of information that passes through the URLs of the front channel.
  • Polymorphic JSON. The protocol elements have different data types that convey additional contextual meaning, allowing us to avoid mutually exclusive protocol elements and design a more succinct and readable protocol. This lets us pass things by reference or by value using the same element field, among other things.
  • Key proofing and presentation. While OAuth 2 thrived on client secrets and bearer tokens, XYZ seeks to   move beyond that at the base level , making use of a variety of security technologies.
  • Ease of transition from OAuth 2. Even though this is not backwards compatible, there should be a   clear translation path from OAuth 2 based systems to XYZ .
  • Inline negotiation. Whenever possible, the protocol is designed such that   discovery and registration are not needed , but they can still be supported.

And most importantly, XYZ seeks to build out a protocol that   doesn't have the same assumptions as OAuth 2

Healthcare Sector and Its Ability to Utilize AuthN and AuthZ protocols

 

For Providers/Staff – Sure thing. 

These people are identity assured as part of their onboarding process

These people’s identities are maintained in commercial identity and access management services (especially in a large enterprise with multiple systems an individual may have access to) Okta, ForgeRock, etc.

-          HR system

-          Clinical systems

-          Analysis/Reporting systems

Identity & Access Management Systems typically allow SSO and management from a single interface (adding/removing users, changing their access rights, etc.)

 

For Patients – Not so much

These people aren’t typically identity assured as we understand the concept

The identity is maintained in an EMPI that is used to disambiguate (match/remediate) a patient’s identity

EMPI is not an Identity Service

Access controls for patients exist only around the Patient Portal (username/password)