Recently, I have been surprised at how little some of the application architects I interact with seem to know about the principles of authentication, and I mean, these are smart people too! When I went out to look on the internet to find some white papers I could send their way; I really found nothing of value. So, while this is in initial draft document, and I haven’t obtained any feedback from my fellow Security Architects, I am providing it here for the interested to get a better understanding of my views, as a security architect, of some of the basic principles of Authentication that I have always taken for granted.
Principles of Authentication
Defining a secure method of participant identification
Terms & Definitions
A participant is an identity taking part in a business communication transaction. A participant may be represented by an end user, a target system, or even an entity facilitating the transmission of communication between two unique identities. A participant may have multiple identities within multiple security domains, but should be uniquely identified with a single identity within a single security domain. An example of participants may be a business user, a database, or a web service.
Identification is the method by which a participant asserts their unique identity within a security domain to another participant within that security domain.
Authentication is the act of validating a participant based on the participant’s asserted claims or identity attributes. Authentication requires a shared secret between participants or attestation from a trusted source that asserts the integrity of the participant’s claims.
Authorization is the act of approving access for an identity to a resource based on a successful authentication.
The purpose of Identification, Authentication and Authorization is to maintain accountability tied to a unique identity within a single security domain, to ensure the integrity, confidentiality and availability of a system and its associated data.
Security Domain / Boundary
A security domain represents a functional environment that maintains a governed trust between participants either through shared secrets or through the use of another participant acting as an arbitrator to attest to the authenticity of participant’s claims.
A claim is a statement of fact about a participant used to assert an identity for authentication. A claim is usually a data artifact that is questionable in nature (e.g. I am who I say I am).
General Guiding Principles
A participant may have multiple identities, but an identity must be unique within a single security domain.
Identification, Authentication, Authorization and Accountability requirements should be dictated by the level of assurance within the system and the associated data classification.
Identities must be authenticated and appropriately authorized before obtaining access to non-public data.
Identities must be re-authenticated when crossing security boundaries.
Authentication of Participants
In order to ensure the confidentiality and integrity of business communications that contain non-public classified data, all participants within a business transaction must be authenticated before being allowed to participate within that business transaction. The foundation of authentication is based off of three primary principles where a participant asserts their claim of identity through something they know, something they have, or something they are.
Take for example, a person (participant) may walk up to the security guard of an organization (participant) and say (claim), “Hello, my name is Jack, please let me in”. While Jack has identified himself, there has been no assertion made proving his claim. The security guard may now ask Jack to enter his personal identification (PIN) code (something he knows), may ask him swipe an RFID badge or present a driver’s license (something he has), or may ask him to have his retina scanned (something he is), in order to provide access for Jack to the building.
After authenticating Jack, the security guard provides him with a badge that will attest to Jack’s authorization to be inside of the building. Jack has now crossed the security boundary of the outside world, into the organizations world. Jack as a participant, now has two identities, his identity associated with his license, and his identity associated with the badge he was provided.
In this scenario, we have identified the three principle foundations of Authentication: 1) something you know, 2) something you have, and/or 3) something you are. Additionally we have identified both direct and indirect forms of authentication, and have illustrated the principle necessity of a security boundary for appropriate authentication and authorization.
All three authentication principles, as well as the concepts of direct and indirect authentication and security boundaries are discussed within the remainder of this document.
Three principles of Authentication
Shared Secret (Something you know)
A Shared Secret is one of the foundational principles that often drives authentication. The secret represents information maintained between two participants that can be used to uniquely identify one or both of the participants within a security domain.
Within the example above, a shared secret was previously configured between the organization and Jack, such that, if Jack was able to provide that shared secret back to the organization, the organization could be reasonably sure that Jack was indeed who he claimed to be. In this scenario, as the organization was able to verify Jack’s claim directly, this was a form of direct authentication.
Token (Something you have)
A token is another form of authentication that represents a claim or a collection of claims that can be used to attest to a participant’s unique identity within a security domain. Tokenized authentication is based on a predefined trust between participants or security domains.
Within the example above, we identified multiple types of tokens that Jack may use. The first type of token was an RFID badge issued by the organization. Because the organization has a direct means to authenticate Jack based on a previously established relationship, this is another example of a direct authentication.
The second type of token discussed was Jack’s license. If the guard chose to authenticate Jack on the license he presented, the guard would be confirming Jack’s identity based on the attestation provided by a trusted third party (another participant). As the guard’s knowledge of Jack relies on the attestation of a third party, this is referred to as indirect authentication.
Within the context of our example, the security guard can use the indirect authentication method to verify Jack’s identity. As there are no current trusts established between the building security system and the license issuing authority, Jack will cross a security boundary, and this indirect authentication cannot be used to grant authorization for Jack to enter the building.
Thus, the security guard must, based on his indirect authentication, provide Jack with a set of claims that are understood within the organization itself, so Jack can be directly authenticated within the building complex. This repacking of claims from one authentication participant to another authentication participant is often referred to as Federated Authentication.
The organization may also implement another security framework in which a trust could be established between the security domains of the organization and the license issuing authority, such that Jack could authenticate to the organization’s security system directly using his license. This authentication framework is a form of pass-through authentication.
Unique characteristics (Something you are)
A unique characteristic of a participant is another form in which a participant may be identified. Unique characteristics of a user might include facial recognition, fingerprinting, voice recognition or retina scanning. Note that this form of authentication is typically used to authenticate user participants as it is arguably easier to replicate the “unique” characteristics of a non-biological entity.
Once a participant has been uniquely identified within a security domain, the participant that is facilitating the business communication must make a decision as to whether or not an authenticated identity has been approved to operate on a secured resource. The discussion of detailed authorization requirements are outside of the scope of this document, however, future documents may be written to address authorization specifics in more detail.
The primary goal in providing identification, authentication and authorization is to ensure accountability throughout a business system or organization. Thus, it is incumbent upon a system that has first identified, authenticated and authorized a participant to access a business resource to keep proper records of what the participant has done with their granted access. The decision of detailed accountability requirements are outside of the scope of this document, however, further documents may be written to address accountability specifics in more detail.