made necessary by autobuild limitations that forced us to build native components separate from the java components.
		
			
				
	
	
		
			91 lines
		
	
	
		
			4.3 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			91 lines
		
	
	
		
			4.3 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| /***********************************************************************
 | |
|  *
 | |
|  *  README for auth_token
 | |
|  *
 | |
|  ***********************************************************************/
 | |
| 
 | |
| INTRODUCTION
 | |
| 
 | |
| CASA-auth-token is an authentication token infrastructure with support for multiple
 | |
| 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
 | |
| configured on a per-service basis. Because of this feature, we say that CASA-auth-token
 | |
| 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.
 | |
|  
 | |
| 
 | |
| 
 | |
| 
 | |
|                 
 | |
| 
 | |
| 
 | |
| 
 | |
| 
 | |
| 
 |