Authentication Gateway Service

The authentication gateway service (AGS) architecture supports requirements from varied applications by mapping user-presented credentials, such as a certificate on a smart card, to a format suitable for the application or service. For example, the AGS can provide proxy/brokered authentication for applications unable to natively support PKI authentication.

Brokered authentication allows for a more secure and standard authentication method. The service can also provide username/password authentication. From a best practices standpoint, an AGS would be used only for credentials of the same level of security assurance. As an example, an AGS instance would only be used for certificate authentication. If username/password is also used, it is authenticated on a separate AGS. Provider-relying parties only use an AGS that meets their authentication assurance level requirements.

Once a consumer’s credential is verified via a directory or PKI service, the AGS is configured to query other data sources, such as identity attribute services, and pass the data on to the application.

Figure 1 – An example of an AGS brokering among authentication protocols and networking protocols.

The AGS in 1 is extensible and can be configured with standard protocols on the front end for the cloud consumer, or on the back end to process any protocols required by cloud provider services. Figure 1 shows one session protocol and two types of authentication tokens for the cloud consumer. On the back end, it processes two separate types of session protocols for the cloud provider. It can also provide authentication tokens to the providers in an SSO configuration.