auth_token/README

@@ -0,0 +1,90 @@
+/***********************************************************************
+ *
+ *  README for auth_token
+ *
+ ***********************************************************************/
+
+INTRODUCTION
+
+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 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.
+ 
+
+
+
+                
+
+
+
+
+

auth_token/TODO

@@ -0,0 +1,17 @@
+/***********************************************************************
+ *
+ *  TODO for auth_token
+ *
+ ***********************************************************************/
+
+INTRODUCTION
+
+This file contains a list of the items still outstanding for auth_token.
+
+Note: There are TODO lists under each auth_token component. This file just
+details outstanding items at the project level.
+
+OUTSTANDING ITEMS
+
+- Plug-in auth_token into the CASA make system.
+