CASA/CASA-auth-token/client/library
S Rahul b9fa3eab0c Multiple changes for Bug #543064
1. Provided SetATSHostList() API for changing the ATS address dynamically
2. Not using CASA enabled server as ATS. ATS address has to be explicitly set
   in client.conf or through SetATSHostList()
3. Not normalizing CASA enabled server's host name while obtaining CASA tokens.
   Callers of ObtainAuthTokenEx() have to pass normalized name as argument
2009-10-09 08:46:35 +00:00
..
linux Changing the RPC retry logic to be bounded by time rather than by the 2008-07-09 17:51:22 +00:00
mechanisms Two changes: 2009-09-25 06:06:03 +00:00
test Added flush AuthToken cache API. 2007-04-13 19:21:40 +00:00
windows Multiple changes for Bug #543064 2009-10-09 08:46:35 +00:00
authmech.c 2007-04-02 22:16:07 +00:00
authmsg.c 2007-04-02 22:16:07 +00:00
authpolicy.c More changes to resolve issues brought up during the security 2007-02-06 22:09:00 +00:00
cache.c Added retries for RPCs that fail due to connection errors. 2008-06-30 20:41:06 +00:00
client.conf The client now tells Curl to look for certificates in /etc/ssl/certs 2007-06-01 23:26:28 +00:00
config_if.h Made the following changes: 2007-03-05 06:48:26 +00:00
config.c Fixed issues found when testing the auth.policy mechanism_info changes 2007-03-26 21:45:10 +00:00
engine.c Multiple changes for Bug #543064 2009-10-09 08:46:35 +00:00
getpolicymsg.c 2007-04-02 22:16:07 +00:00
gettokenmsg.c 2007-04-02 22:16:07 +00:00
internal.h Modified client to try to authenticate a user against a list of 2007-05-29 22:59:50 +00:00
invalidcert.c Addressed issues found during the SuSE security review. 2007-02-02 23:02:43 +00:00
Makefile.am CASA-auth-token-client: rename lib directory to library and change in makefile 2007-01-03 05:04:26 +00:00
mech_if.h 2007-04-02 22:16:07 +00:00
README CASA-auth-token-client: rename lib directory to library and change in makefile 2007-01-03 05:04:26 +00:00
TODO Updated changes and todo files. 2007-06-04 17:24:49 +00:00
util.c Made the following changes: 2007-03-05 06:48:26 +00:00

/***********************************************************************
 * 
 *  Copyright (C) 2006 Novell, Inc. All Rights Reserved.
 *
 *  This library is free software; you can redistribute it and/or
 *  modify it under the terms of the GNU Lesser General Public
 *  License as published by the Free Software Foundation; version 2.1
 *  of the License.
 *
 *  This library is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 *  Library Lesser General Public License for more details.
 *
 *  You should have received a copy of the GNU Lesser General Public
 *  License along with this library; if not, Novell, Inc.
 * 
 *  To contact Novell about this file by physical or electronic mail, 
 *  you may find current contact information at www.novell.com.
 * 
 *  Author: Juan Carlos Luciani <jluciani@novell.com>
 *
 ***********************************************************************/
/***********************************************************************
 *
 *  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.

CONFIGURATION

libcasa_c_authtoken has several configuration settings that can be modified to
change its default behavior. To modify the libcasa_c_authtoken configuration
you need to edit the client.conf file. The path to the client.conf file under
linux is /etc/CASA/authtoken/client/client.conf. The path to the client.conf file
under windows is \Program Files\novell\CASA\Etc\Auth\client.conf.

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/CASA/authtoken/client/mechanisms/.
The path to this folder under Windows is \Program Files\novell\CASA\Etc\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.