2006-05-01 18:28:02 +02:00
|
|
|
/***********************************************************************
|
|
|
|
*
|
|
|
|
* README for auth_token
|
|
|
|
*
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
INTRODUCTION
|
|
|
|
|
2006-06-19 22:14:49 +02:00
|
|
|
CASA-auth-token is an authentication token infrastructure with support for multiple
|
2006-05-01 18:28:02 +02:00
|
|
|
authentication mechanisms with an emphasis on providing a scalable single
|
|
|
|
sign-on solution.
|
|
|
|
|
|
|
|
A key feature of auth_token is that its authentication tokens contain identity
|
|
|
|
information about the entity being authenticated. This information is made available
|
|
|
|
to the consuming services. The amount of information contained in the tokens is
|
2006-06-19 22:14:49 +02:00
|
|
|
configured on a per-service basis. Because of this feature, we say that CASA-auth-token
|
2006-05-01 18:28:02 +02:00
|
|
|
projects an "Authenticated Identity".
|
|
|
|
|
|
|
|
ARCHITECTURE COMPONENTS
|
|
|
|
|
|
|
|
The infrastructure provided by auth_token consists of client and server components.
|
|
|
|
|
|
|
|
The client components of auth_token consists of a Client Engine, Get Authentication
|
|
|
|
Token API, Authentication Token Cache, and Authentication Mechanism plug-ins.
|
|
|
|
|
|
|
|
The server components of auth_token consists of an Authentication Token Service, a
|
|
|
|
Verify Authentication Token API, a JAAS module, a PAM module, and an Apache Authentication
|
|
|
|
Provider module. The Authentication Token Service makes use of Authentication Mechanism
|
|
|
|
plug-ins, an Identity Data Store Abstraction Layer, and of Identity Token Providers.
|
|
|
|
|
|
|
|
SECURITY FEATURES AND DATA FLOW
|
|
|
|
|
|
|
|
Communications between the Client Engine and the Authentication Token Service (ATS)
|
|
|
|
occur over HTTPS. When a client desires to obtain an Authentication Token to access
|
|
|
|
a particular service it contacts an ATS which then proceeds to inform the client about
|
|
|
|
the Authentication Policy configured for the service. The policy contains information
|
|
|
|
about authentication mechanisms supported as well as information about the types of
|
|
|
|
credentials that the client can utilize to authenticate to the ATS. Once the client
|
|
|
|
receives the Authentication Policy, it then decides what authentication mechanism to
|
|
|
|
utilize to authenticate to the ATS based on the available authentication mechanisms
|
|
|
|
plug-ins as well as the available credentials. During the authentication process, the
|
|
|
|
ATS associates an identity with the entity being authenticated. The result of this
|
|
|
|
resolution is saved in a Session Token which is then sent to the client where it is
|
|
|
|
cached. Once the client is authenticated to the ATS, it then requests Authentication
|
|
|
|
Tokens from it using the obtained Session Token. When an ATS receives a request for
|
|
|
|
an Authentication Token, it then verifies the validity of the received Session Token
|
|
|
|
and then it creates the appropriate Identity Token for the target service which it then
|
|
|
|
embeds within the Authentication Token. The indentity information contained in the
|
|
|
|
Identity Token as well as the type of Identity Token utilized depends on what is
|
|
|
|
configured for the tatget service.
|
|
|
|
|
|
|
|
Session Tokens and Authentication Tokens are signed by the issuing ATS using Signing
|
|
|
|
Certificates. Session Tokens and Authentication Tokens have a Lifetime Value associated
|
|
|
|
with them. Token verification involves verifying the token signatures, verifying that
|
|
|
|
the tokens where signed by a trusted entity, and verifying that the token lifetime has
|
|
|
|
not been exceeeded.
|
|
|
|
|
|
|
|
The auth_token client/service protocol allows for the authentication of the client entity.
|
|
|
|
auth_token relies in the server authentication mechanisms of SSL to verify the identity
|
|
|
|
of the ATS.
|
|
|
|
|
|
|
|
IMPLEMENTATION STRATEGY AND CURRENT STATUS
|
|
|
|
|
|
|
|
auth_token is currently under development and is not ready to be used in production.
|
|
|
|
The implementation strategy has been to first complete the framework with all of its
|
|
|
|
modules, APIs, and packaging to allow application writters to start developing to it.
|
|
|
|
Once this is done, then the implementation focus will switch to completing the plumbing.
|
|
|
|
|
|
|
|
As of this time, a lot of the framework has been completed and there are sample
|
|
|
|
applications that can be utilized to exercise it. For a more complete picture of where
|
|
|
|
we are, look at the various TODO lists present in the child folders.
|
|
|
|
|
|
|
|
The schedule for completing auth_token is agressive.
|
|
|
|
|
|
|
|
SECURITY CONSIDERATIONS
|
|
|
|
|
|
|
|
CASA Authentication Tokens when compromised can be used to either impersonate
|
|
|
|
a user or to obtain identity information about the user. Because of this it is
|
|
|
|
important that the tokens be secured by applications making use of them. It is
|
|
|
|
recommended that the tokens be transmitted using SSL.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|