CASA/auth_token/client
2006-05-08 15:17:51 +00:00
..
mechanisms Project changes reflecting the rename of the win32 folder. 2006-05-08 15:17:51 +00:00
test Changes due to continued development effort. 2006-04-28 19:00:04 +00:00
windows Modified the folder name to be compatible with the make system for windows. 2006-05-05 23:21:16 +00:00
authmech.c Changes due to continue development effort. 2006-04-28 18:58:25 +00:00
authmsg.c Changes due to continue development effort. 2006-04-28 18:58:25 +00:00
authpolicy.c Changes due to continue development effort. 2006-04-28 18:58:25 +00:00
client.vcproj Changes due to rename of platutils.c to platform.c. 2006-04-28 19:06:24 +00:00
config_if.h Changes due to continue development effort. 2006-04-28 18:58:25 +00:00
config.c New client components for Casa Authentication. 2006-04-03 20:20:37 +00:00
engine.c Changes due to continue development effort. 2006-04-28 18:58:25 +00:00
getpolicymsg.c Changes due to continue development effort. 2006-04-28 18:58:25 +00:00
gettokenmsg.c Changes due to continue development effort. 2006-04-28 18:58:25 +00:00
internal.h Changes due to rename of platutils.c to platform.c. 2006-04-28 19:06:24 +00:00
mech_if.h Changes due to continue development effort. 2006-04-28 18:58:25 +00:00
README New files. 2006-05-01 17:38:04 +00:00
TODO New files. 2006-05-01 17:38:04 +00:00
util.c Changes due to continue development effort. 2006-04-28 18:58:25 +00:00

/***********************************************************************
 *
 *  README for libcasa_c_authtoken
 *
 ***********************************************************************/

INTRODUCTION

libcasa_c_authtoken is the client auth_token engine. It is responsible for
interacting with ATSs, invoking the authentication mechanism plug-ins, and
managing the authentication token cache. libcasa_c_authtoken also provides
the Get Authentication Token API.

CONFIGURING ADDITIONAL AUTHENTICATION MECHANISM MODULES

libcasa_c_authtoken utilizes mechanism plug-ins for authenticating to ATSs.
The client auth_token package installs mechanisms for the support of Kerberos5
and Username/Password authentication. To configure additional authentication mechanism
plug-ins, place their configuration file in the folder for CASA Authentication Token module
configuration. The path to this folder under linux is /etc/opt/novell/CASA/authtoken.d/modules.d.
The path to this folder under Windows is \Program Files\novell\CASA\auth\mechanisms. The name of
the plug-in configuration file is related to the authentication mechanism type in the following
manner: AuthenticationMechanismTypeName.conf.

Authentication Mechanism plug-in configuration files must must contain a directive indicating the
path to the library implementing the Authentication Mechanism (See the configuration file
for the Kr5Authenticate plug-in for an example).

CLIENT APPLICATION PROGRAMMING NOTES

The Get CASA Authentication Token API is defined in casa_c_authtoken.h.

The API consists of a call to obtain authentication tokens. The caller must supply the name of the
service to which it wants to authenticate along with the name of the host where it resides. The
returned authentication token is a Base64 encoded string.

Applications utilizing CASA Authentication Tokens as passwords in protocols that require the
transfer of user name and password credentials should verify or remove any password length limits
as the length of CASA Authentication Tokens may be over 1K bytes. The size of the CASA Authentication
Tokens is directly dependent on the amount of identity information configured as required by the
consuming service. These applications should also set the user name to "CasaPrincipal".

For examples of code which uses the Get CASA Authentication Token API look at the test application
under the test folder.

AUTHENTICATION MECHANISM PROGRAMMING NOTES

The Authentication Mechanism API is defined in mech_if.h.

For example implementations see the code for the krb5 and the pwd mechanisms.

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.