Since each Federation member will provide the basic information listed above, all service providers within this Federation will be able to make an informed decision about the confidence that an authenticated user is indeed the correct individual. This confidence is also know as the level of assurance. Each application (or service provider) must evaluate its application needs to determine if the level of assurance provided by each Federation member meets these security requirements. The remainder of this section provides background and guidance in making this type of determination.
This section summarizes the US Office of Management and Budget's (OMB) memorandum concerning guidance for e-authentication within the federal government [OMB-04-04]. In addition, it summarizes the accompanying National Institute of Standards and Technology (NIST) recommendations [NIST-04-04]. These documents define the federal standard for security level access to electronic applications and information:
-
Level 1 - Little or no confidence in the asserted identity’s validity
-
Level 2 - Some confidence in the asserted identity’s validity
-
Level 3 - High confidence in the asserted identity’s validity
-
Level 4 - Very high confidence in the asserted identity’s validity
These levels of assurance are applicable for two different types of authentication:
-
Identity authentication - The process of confirming a person's unique identity.
-
Attribute authentication - The process of confirming that the unique person (once the identity is authenticated) is correctly represented by the claimed attributes.
Furthermore, these documents identify the following categories of harm and impact due to purposeful or inadvertent mis-authentication:
-
Inconvenience, distress, or damage to standing or reputation
-
Financial loss or agency liability
-
Harm to agency programs or public interests
-
Unauthorized release of sensitive information
-
Personal safety
-
Civil or criminal violations
The following section provides the guidance needed for each service provider to perform a risk analysis of an application to determine the required level of assurance for the application at hand. However, no all inclusive template exists for this type of analysis as it largely depends on the environment and application-specific requirements.
Due to the distributed nature of the Federation, service providers are not able to perform either identity or attribute authentication first-hand. As such, the service provider must TRUST the entity supplying both the identity assertions and the attribute assertions. However, trust between people and organizations is difficult to establish and maintain. By transparently disclosing operating policies and practices, federated entities can independently evaluate this information to determine a level or assurance that the asserted credentials are both precise and accurate. The remainder of this section provides the framework needed to make these types of determinations.
For each of the six categories listed above, all applications should be analyzed to determine the potential impacts of a security breach. The impact for each category will be dramatically different based on the type of application, the information it requires, and the manner with which individuals access it. The direct impact measurement scale used by the federal government is defined as:
-
Low Risk
-
Moderate Risk
-
High Risk
For a detailed discussion of the exact meaning of each impact type on the individual categories, please refer to the [OMB-04-04] memorandum. Once the degree of impact is determined, one must assess the likelihood that this type of error/breach will occur.
While the degree and frequency of a breach both determine the needed level of assurance, the degree is often the dominant factor assuming the likelihood is greater than 0 percent. Therefore, the following table can be used to determine the appropriate level of assurance required to meet the minimum security requirements:
Table 1.1. Maximum Potential Impact Profiles
| Potential Impact Categories for Authentication Errors | Assurance Level | |||
| 1 | 2 | 3 | 4 | |
| Inconvenience, distress, or damage to standing or reputation | Low | Mod | Mod | High |
| Financial loss or agency liability | Low | Mod | Mod | High |
| Harm to agency programs or public interests | N/A | Low | Mod | High |
| Unauthorized release of sensitive information | N/A | Low | Mod | High |
| Personal safety | N/A | N/A | Low | Mod/High |
| Civil or criminal violations | N/A | Low | Mod | High |
Once the appropriate assurance level has been identified, the information provided by each Federation member must be evaluated in order to determine if it meets the required level. While all of the information must be taken into account, the type of authentication token used by each member plays a dramatic role in determination of the assurance level. While the Federation does NOT specify the required token type, all such credentials will likely be based on userids and passwords, which is in contrast to cryptographically signed name badges, software certificates or other more secure forms of authentication. The following table maps various authentication tokens to the familiar assurance levels:
Table 1.2. Token Type Assurance Mappings
| Allowed Token Types | Assurance Level | |||
| 1 | 2 | 3 | 4 | |
| Hard Crypto Token | Yes | Yes | Yes | Yes |
| Soft Crypto Token | Yes | Yes | Yes | - |
| One-time Password Device | Yes | Yes | Yes | - |
| Strong Password | Yes | Yes | - | - |
| PIN | Yes | - | - | - |
This table implies that the highest assurance level provided by the Federation (assuming userid and password authentication) is level 2 (some confidence in the asserted identity’s validity). Applications that require higher levels of assurance should NOT use the Federation as a means of authentication. In everyday usage, an assure level of 2 means that the application is reasonably confident the true identity of the authenticated individual is equivalent to the identity asserted by the identity provider.
However, reasonable assurance of an individual's identity does NOT necessarily imply reasonable attribute authentication assurance. In other words, the attribute assurance is more dependent on the internal processes of the identity provider to keep the information accurate and fresh. For example, the "current address" of an authenticated is user is only as accurate as the process for collecting, verifying, and maintaining that data from the original identity provider. Therefore, if authorization decisions are made based on asserted identity attributes, then the service provider must take the maintenance of this data into account when determining if the actual assurance level meets the minimum requirements for the application in question.
Once an application has been implemented, the service provider should conduct a final analysis to ensure if implementation decisions did not negatively affect the security of the application. This analysis should verify that the actual assurance level of the application meets the predefined minimum.
Change is inevitable in both application requirements and business processes. As a result, the assurance level of all applications should be re-evaluated on a periodic basis. This re-evaluation should include both the required assurance level and the actual assurance level. Evaluating the actual level ensures the application and its data is consistent with the all previous assumptions. Naturally, a change in required level will necessitate changes to the authentication structure. On the other hand, the actual assurance level depends on the operating policies and practices of the Federation members as well as the application implementation decisions. The service provider should ensure changes in these business practices have not altered the actual assurance level of the delivered application.
In theory, the Federation can provide any level of assurance (1-4) required of an application. However in practice, the local identity provider's likely authentication method (userid and password) restricts usage to applications requiring at most level 2 security. When creating a service to be consumed by Federation members, that service provider must follow these steps in order to establish an appropriate level of assurance for the application in question:
-
Conduct a risk analysis
-
Map risks to a level of assurance
-
Evaluate participating members to ensure minimum levels of assurance are met
-
Validate post implementation
-
Reassess periodically
Since each entity is required to provide a basic set of pertinent metadata, then service providers will have the information required to make an informed decision during the process listed above. Furthermore, transparency between members will facilitate better levels of assurance in the future as business processes are continuously revised and improved.