Archive for July, 2009

Configuring OpenDS as a User Data Store in OpenSSO

July 14, 2009
In recently released OpenSSO Express 7 are several impressive capabilities, including support for OpenDS Standard Edition as a repository for user profiles, authentication data, and policies. You need perform only a few configuration steps, as detailed in a procedural article in the OpenSSO Resource Center.

The article also includes several sections of reference information: troubleshooting tips, the OpenSSO features that work with various directory servers, a few policy and interface nuances that might help you determine which user data store to use. Have a look.



Single Sign-on and the OBSSOCookie

July 13, 2009

The Oracle Access System implements single-domain and multi-domain single sign-on
through an encrypted cookie called the ObSSOCookie. The WebGate sends the
ObSSOCookie to the user’s browser upon successful authentication. This cookie can
then act as an authentication mechanism for other protected resources that require the same or a lower level of authentication.

When the user requests access to a browser or another resource, the request flows to
the Access Server. The user is logged in, and the ObSSOCookie is set. The Access
Server generates a session token with a URL that contains the ObSSOCookie. Single
sign-on works when the cookie is used for subsequent authorizations in lieu of
prompting the user to supply authorization credentials.

When the cookie is generated, part of the cookie is used as an encrypted session token.

The encrypted session token contains the following information:
– The distinguished name (DN) of the authenticated user.
– The level of the authentication scheme that authenticated the user.
– The IP address of the client to which the cookie was issued.
– The time the cookie was originally issued.
– The time the cookie was last updated.

If the user has not been idle, the cookie is updated at a fixed interval to prevent the session from timing out. The update interval is one-fourth of the length of the idle session timeout parameter.

Unencrypted ObSSOCookie data includes:
– Cookie expiry time.
– The domain in which the cookie is valid.
– An optional flag that determines if the cookie can only be sent using SSL.
Security of the ObSSOCookie

The ObSSOCookie is a secure mechanism for user authentication. When the Access
System generates the cookie, an MD-5 hash is taken of the session token. When the
ObSSOCookie is used to authenticate a user, the MD-5 hash is compared with the
original cookie contents to be sure no one has tampered with the cookie. MD-5 is a
one-way hash, so it cannot be unencrypted. The Access Server does the comparison by
hashing the session token again and comparing the output with the hash of the token
already present in the cookie. If the two hashes do not match, the cookie is corrupt.
The system relies on the fact that if someone tampers with the session token, the
hashes will not match.

The single sign-on cookie does not contain user credentials such as user name and


Credential Mapping Error – Oracle Access Manager

July 13, 2009

Setting up IWA is a fairly straight forward task. All you need are an OAM environment, an IIS server with WebGate installed and special IWA Authentication Scheme. The IWA specific authentication scheme requires a credential mapping plugin to map the REMOTE_USER HTTP header variable set by IIS to a user attribute in the OAM user directory. WebGate even takes care of parsing the domain name from REMOTE_USER for you, what could be easier?

So assuming you followed all of hte instructions and everything is set up perfectly, or at least you think it is, what do you do if you still have a problem. Specifically, what could be wrong if are getting a credential mapping error in the web browser and the access server oblog.log file.

I recently encountered just such a problem. I used the search base and filter from the credential mapping plugin and conducted my own search against the directory as the OAM service account and it worked perfectly. This was so puzzling. I looked for trailing spaces in the credential mapping plugin because I know that can occur with resource patterns and ldap urls in other parts of Policy Manager. I finally compared a working credential mapping plugin to the IWA one. The different was in the quotation marks. The IWA credential mapping had been copied and pasted from the Metalink article discussing how to set up IWA in OAM. They were obviously from the wrong character set. Replacing the quotation marks solved the problem.


Requirements for SSO Across Disparate Policy Servers

July 13, 2009

SSO across disparate SiteMinder policy-store environment requires the following:

1. Same Encryption Key on all policy servers.

2. Same Agent and Session Keys or, better yet, same keystore, on all policy servers.

3. Same User Directory SiteMinder object names and same User DN’s, in all policy stores.

This case concerns the “key” side of the question, which should be satisfied as follows:

– Policy Store encryption keys must be the same. These are set at installation.

– Agent keys on each policy server should be rolled statically on all policy servers – or, if some policy stores are not configured for agent key rollover per smconsole, then at least on all those that are configured for rollover. This is set through the “Enable Agent Key Generation” checkbox on smconsole for each policy server.

Using the SiteMinder Administrative UI’s “SiteMinder Key Management” dialog, accessed through the “Tools” menu’s “Manage Keys” option:

In the Agent Key tab, type in and confirm the same “Static Key” on all policy servers, and click “Rollover Now.” Ensure that “Use static Agent key” is checked at the top of this tab.

Subsequently, in the Session Ticket Key tab, enter an identical string in the “Session Ticket Key”and “Confirm” fields under “Specify a Session Ticket Key” – identical across all policy servers – and click the “Rollover Now” button.


How can I prevent spoofing CA SiteMinder?

July 13, 2009

According to Wikipedia, “a spoofing attack is a situation in which one person or program successfully masquerades as another by falsifying data and thereby gaining an illegitimate advantage.” All SSO solutions are prone to facing situations where a valid session cookie is used to attempt to open another HTTPS SSL session. The key to avoiding this situation is to prevent the cookie from being accessed to begin with, and there are several ways to do this:

  1. Use the Secure Cookies option on the web agent to prevent the cookie from being sent to non-SSL enabled web servers.
  2. Use transient cookies instead of persistent cookies.
  3. Always enable SSL between the browser and the web agent.
  4. Enable the IP Checking feature to ensure that the cookie is validated against the user’s IP address.
  5. Shorten the length o the Max Session & Idle Session timeout values for your SiteMinder realms.
  6. Roll over agent keys at shorter intervals.

SiteMinder Authentication via SQL Stored Procedure

July 12, 2009

SiteMinder’s documentation provides some basic guidance on the proper format to use when building a SQL stored procedure to handle authentication. The documentation reads:

If a stored procedure is required for ODBC authentication:


When you configure the directory, the SQL query of the ODBCQuery object

associated with the user directory must call the stored procedure as follows

Call %s, %s

For example:

Call EncryptPW %s, %s

On the database, the stored procedure used to authenticate must meet these


. The stored procedure must return an integer value.

. The first procedure parameter is the UserName Parameter and the second

is the password parameter.

. All parameters must be defined with the keyword OUT.

Here is an SQLServer example:


@UserName varchar(20) OUT ,

@PW varchar(20) OUT


SELECT from Smuser where @UserName and password = @PW

SELECT Smuser.password from Smuser where name= @UserName and password = @PW

return 0

A recent client of mine wished to move authentication to a SQL stored procedure (sproc) while maintaining a custom hashing algorithm in the form of a .NET component. The sproc needed to call out to this DLL (which was registered as an assembly within SQL server) to determine whether the provided password matched with the value stored in the database. I used the sample provided in the SiteMinder documentation to construct the sproc, and I added my custom logic above the final SELECT statements. Unfortunately SiteMinder consistently errored out when calling the sproc, and the logs showed the following error:

[DataDirect][ODBC SQL Server Driver]Function sequence error][][][]

After multiple attempts to isolate where this query was failing, we were finally able to pinpoint the cause. The sproc was missing one simple line of code at the top:


You can read about NOCOUNT here, but the bottom line is not having this statement in place was causing SiteMinder to receive unexpected results from SQL Server.

So if you’re going to be using any custom auth logic beyond the sample provided in the SiteMinder guides, be sure the format looks like this:


@UserName varchar(20) OUT ,

@PW varchar(20) OUT




SELECT from Smuser where @UserName and password = @PW

SELECT Smuser.password from Smuser where name= @UserName and password = @PW

return 0


How SiteMinder Caches Work

July 12, 2009

Caches implemented by the Policy Server

Object Store Cache
Purpose: Stores contents of the Policy Store in memory in order to reduce round trip calls to LDAP and ODBC policy stores.
Type: Key/Value map.
Key: Object ID
Value: Object
Entry added:
· All objects are added at the startup time.
· Every time an object or an object property is fetched from the Policy Store
Entry removed: Whenever an object is invalidated due to creation/deletion/modification.
Configuration: No parameters. Always fully preloaded
Comments: The Policy Cache is actually an array of caches – one element of this array corresponds to one object type (domain, realm, etc.). Successful read access is not blocking. Thread will have to obtain a lock only if it tries to modify the cache.

Policy Cache
Purpose: Stores the list of policy links applicable to a given resource and action. Prevents the scanning of all rules within a given realm in order to determine which policies protect a particular resource.
Type: Two level cache. The first level is the Key/Value map, the second level is tree of lexical rule filters + array of regexp rule filters.
First level Key: RealmOID (or Agent OID in case of Global Policies) of a protected resource.
First level Value: Data describing the realm.
Second level Key: Resource+Action.
Second level Value: Tree of lexical rules pointing to lists of applicable policy links. Map of regexp rules pointing to lists of applicable policy links.
Cache lifetime: Cache rebuilt if needed at the end of the Management cycle. If some relevant object were modified, cache will be completely rebuilt from Object Cache. While cache is building no requests are served.
Configuration: None
Comments: New in SiteMinder 6.0

Agent Name Cache
Purpose: Stores easy searchable table of Agent Oids. During IsProtected it is necessary to determine Agent Oid from Agent Name. The Agent Name Cache prevents enumerating all agents to find one with matching name.
Type: Hash Map of Agent Names to Agent Oids
Key: Agent Name
Value: Agent Oid
Cache lifetime: Cache rebuilt if needed at the end of the Management cycle. If some relevant object were modified, cache will be completely rebuilt from Object Cache. While cache is building no requests are served.
Comments: New in SiteMinder 6.0

Agent Group Cache
Purpose: Stores easy searchable lists of Agent Oids. During IsProtected it is necessary to find all Agents that might protect this resource, i.e. if given agent belongs to Agent Group, all agents (and agent groups) of this group might protect given resource. The Agent Group Cache prevents recursive scanning of all agents to find applicable ones.
Type: Multi Map of Agent Oids to list of Agent Oids
Key: Agent Oid
Value: List of Agent Oids
Cache lifetime: Cache rebuilt if needed at the end of the Management cycle. If some relevant object were modified, cache will be completely rebuilt from Object Cache. While cache is building no requests are served.
Comments: New in SiteMinder 6.0

Realm Cache
Purpose: Stores Realms for best resource matching. During IsProtected it is necessary to find best matching Realm for given Agents and resource. The Realm Cache prevents scanning of all Realms to find best lexical match.
Type: Two level cache. First stores Hash Map of Agent Oids, each pointing to Realm Tree. Each Realm
Tree stores Realm filter pointing to Realm OID. The process of finding best matching realm is:
1. For each given Agent, find corresponding tree.
2. Search given resource to find best matching realm in the tree.
3. Pickup the longest match between all applicable Agents.
Key: List of Agent Oids + resource
Value: Realm OID
Cache lifetime: Cache rebuilt if needed at the end of the Management cycle. If some relevant object were modified, cache will be completely rebuilt from Object Cache. While cache is building no requests are served.
Comments: New in SiteMinder 6.0

Server Command Cache
Purpose: Stores Server Commands for configurable amount of time (default 10 seconds) before actually storing them in Policy Store. When changes are made to Policy Store, duplicate commands may be created. Also, “Flush” commands of broader scope overwrite more specific Flush commands. For example, if user initiates “Flush All” command, all other “flush” commands become irrelevant. This is done to decrease overall number of Server Commands.
Type: Commands are treated differently:
· UpdateOid commands stored in hash table, so only last “update” of specific command will be
· “Flash All” : last command stored by itself. Because we should issue only one such command.
· “Flash Realms”: last command stored by itself. Because we should issue only one such
· “Flush Realm”: commands stored in hash table, so only last “flush” of specific realm will be
Cache is cleaned out every “ServerCmdDelay” seconds i.e. all cached commands are stored in
Policy Store.
Key: Server Command
Value: True if proceed with Save or False if skip it.
Entry added: Every time server command is created
Entry removed:
· Once every “ServerCmdTimeDelay”
Registry Value Name Default Commnet
ServerCmdDelay 10 Number of seconds to store Server Commands.
Comments: New in SiteMinder 6.0

User Authorization Cache
Purpose: Stores information about policies applied to a given user. When a policy is bound to a user directory object such as a group it is necessary to determine whether a particular user belongs to the group i.e. it is necessary to search the directory to get the user’s membership list. The User Authorization Cache prevents this round trip to the directory. Note that if a policy is bound to a user name (or DN, OU, and O), the Authorization Cache is ineffective because in this case there is no need to search the directory in the first place.
Type: Key/Value map with timestamp for each entry. When cache limit is reached, 25% of random entries are removed. During a successful lookup the timestamp is checked and the entry is invalidated if it has expired.
Key: Directory+UserDN+PolicyUserFilter+PolicyResolution+PolicyFlags
Value: True (if a policy applies to the user), False otherwise
Entry added: Every time user-policy relationship is found.
Entry removed:
· When the cache limit is reached 25% random entries are removed.
· When the entry has expired.
· When the “FlushAll” or the “FlushUsers” commands are processed all entries are removed.
Configuration: UI: Policy Server management console, “Settings” tab,
“User Az Cache (MB)”
Registry Key: Ds\DsCacheParms
Value Name Default Description
DsInfoEnabled False
DsInfoMaxSizeMB 10 Size of cache in MB
DsInfoTimeoutSeconds 3600 Cache entry expiration time
in seconds
Registry-UI mapping
Registry Value Name UI control name
DsInfoMaxSizeMB User Az Cache (MB)
· Although DsInfoCacheEnabled does not have UI mapping, it will be set to False if DsInfoMaxSizeMB is zero.
· In SiteMinder version 4x/5x User Az Cache defined in number of entries. To improve manageability of prodact, SiteMinder 6.x defines User Az Cache size in MB. Rule used for conversion is:
Number Of MB = Number of entries 64 / ( 1024 1024) + 1 (i.e. each entry estimated as 64 bytes)

Authentication Cache
Purpose: Stores full response packets for a successful user authentication. Prevents a round trip to the LDAP or ODBC user store in order to authenticate a particular user. There are a number of limitations with this cache (see below).
Type: Key/Value map with timestamp for each entry. When cache limit is reached one random entry is removed. During a successful lookup the timestamp is checked and the entry is invalidated if it has expired.
Key: SHA1 Digest of Username+Password+RealmOID
Value: Full response packet
Entry added: Every time a user is successfully authenticated.
Entry removed:
· When the cache limit is reached one randomly selected entry is removed.
· When the entry is expired.
Configuration: UI: None
Registry Key: Authentication
Value Name Default Description
AuthCacheSize 0 0 means that cache is disabled
AuthCacheEntryLifetime 6 0 Cache entry expiration time in minutes
Comments: This cache is currently not documented in any of the SiteMinder end user documentation. The
cache has the following limitations:
· It Works only for password based authentication schemes
· There is no synchronization with the “FlushUser”, “FlushAll” command.
· There is no synchronization with a users session expiration time.

Certificate Revocation List (CRL) cache
Purpose: Stores CRLs. Eliminates search of the CRL Directory during certificate-based authentication.
Type: Unbounded linked list of objects. During successful lookup the “NextUpdate” field of the CRL is checked. If the current time is bigger then the value of that field, the entry is removed.
Key: Issuer DN +Certificate Serial Number
Value: REVOKED (if the certificate is found in the CRL cache),
VALID (if the certificate is not found in the CRL cache),
NOT_FOUND (if the CRL is not cached)
Entry added: when CRL is fetched from the CRL Directory.
Entry removed:
· When the entry is expired (“NextUpdate” field of CRL is in the past).
· When the “FlushAll” command is processed all entries are removed.
Configuration: Configured in Admin GUI in the “Certificate Mapping” dialog box.


Single Sign-on Using Kerberos in Java

July 11, 2009


A significant enhancement to the Java security architecture is the capability to achieve single sign-on using Kerberos Version 5 in the next release of JavaTM Standard Edition (J2SE). A single sign-on solution lets users authenticate themselves just once to access information on any of several systems. This is done using JAAS for authentication and authorization and Java GSS-API to establish a secure context for communication with a peer application. Our focus is on Kerberos V5 as the underlying security mechanism for single sign-on, although other security mechanisms may be added in the future.


With the increasing use of distributed systems users need to access resources that are often remote. Traditionally users have had to sign-on to multiple systems, each of which may involve different usernames and authentication techniques. In contrast, with single sign-on, the user needs to authenticate only once and the authenticated identity is securely carried across the network to access resources on behalf of the user.

In this paper we discuss how to use single sign-on based on the Kerberos V5 protocol. We use the Java Authentication and Authorization Service (JAAS) to authenticate a principal to Kerberos and obtain credentials that prove its identity. We show how Sun’s implementation of a Kerberos login module can be made to read credentials from an existing cache on platforms that contain native Kerberos support. We then use the Java Generic Security Service API (Java GSS-API) to authenticate to a remote peer using the previously obtained Kerberos credentials. We also show how to delegate Kerberos credentials for single sign-on in a multi-tier environment.


Kerberos V5 is a trusted third party network authentication protocol designed to provide strong authentication using secret key cryptography. When using Kerberos V5, the user’s password is never sent across the network, not even in encrypted form, except during Kerberos V5 administration. Kerberos was developed in the mid-1980’s as part of MIT’s Project Athena. A full description of the Kerberos V5 protocol is beyond the scope of this paper. For more information on the Kerberos V5 protocol please refer to [1] and [2]

Kerberos V5 is a mature protocol and has been widely deployed. It is available on Solaris as SEAM and on Windows 2000 and several other platforms. A free reference implementation in C is available from MIT. For these reasons we have selected Kerberos V5 as the underlying technology for single sign-on in J2SE.


Until recently the Java 2 security architecture solely determined privileges by the origin of the code and the public key certificates matching the code signers. However, in a multi-user environment it is desirable to further specify privileges based on the authenticated identity of the user running the code.

JAAS supplies such a capability. JAAS is a pluggable framework and programming interface specifically targeted for authentication and access control based on the authenticated identities.

Authentication and Authorization

The JAAS framework can be divided into two components: an authentication component and an authorization component.

The JAAS authentication component provides the ability to reliably and securely determine who is currently executing Java code, regardless of whether the code is running as an application, an applet, a bean, or a servlet.

The JAAS authorization component supplements the existing Java security framework by providing the means to restrict the executing Java code from performing sensitive tasks, depending on its codesource and depending on who is executing the code.

Pluggable and Stackable Framework

JAAS authentication framework is based on Pluggable Authentication Module (PAM)[3, 4]. JAAS authentication is performed in a pluggable fashion allowing system administrators to add appropriate authentication modules. This permits Java applications to remain independent of underlying authentication technologies, and new or updated authentication technologies can be seamlessly configured without requiring modifications to the application itself.

JAAS authentication framework also supports the stacking of authentication modules. Multiple modules can be specified and they are invoked by the JAAS framework in the order they were specified. The success of the overall authentication depends on the results of the individual authentication modules.


JAAS uses the term Subject to refer to any entity that is the source of a request to access resources. A Subject may be a user or a service. Since an entity may have many names or principals JAAS uses Subject as an extra layer of abstraction that handles multiple names per entity.Thus a Subject is comprised of a set of principals. There are no restrictions on principal names.

A Subject is only populated with authenticated principals. Authentication typically involves the user providing proof of identity, such as a password.

A Subject may also have security related attributes, which are referred to as credentials. The credentials can be public or private. Sensitive credentials such as private cryptographic keys are stored in the private credentials set of the Subject.

The Subject class has methods to retrieve the principals, public credentials and private credentials associated with it.

Please note that different permissions may be required for operations on these classes. For example AuthPermission(“modifyPrincipals”) may be required to modify the principal set of the Subject. Similar permissions are required to modify the public credentials, private credentials and to get the current Subject.

doAs and doAsPrivileged

Java 2 enforces runtime access controls via java.lang.SecurityManager. The SecurityManager is consulted anytime sensitive operations are attempted. The SecurityManager delegates this responsibility to The AccessController obtains a current image of the AccessControlContext and verifies that it has sufficient permission to do the operation requested.

JAAS provides two methods doAs and doAsPrivileged that can be used to associate an authenticated Subject with the AccessControlContext dynamically.

The doAs method associates the Subject with the current thread’s access control context and subsequent access control checks are made on the basis of the code being executed and the Subject executing it.

public static Object doAs(final Subject subject,
final PrivilegedAction action)

public static Object doAs(final Subject subject,
final PrivilegedExceptionAction action)
throws PrivilegedActionException;
Both forms of the doAs method first associate the specified subject with the current Thread’s AccessControlContext, and then execute the action. This achieves the effect of having the action run as the Subject. The first method can throw runtime exceptions but normal execution has it returning an Object from the run() method of its action argument. The second method behaves similarly except that it can throw a checked PrivilegedActionException from its run() method. An AuthPermission(“doAs”) is required to call the doAs methods.

The following methods also execute code as a particular Subject:

public static Object doAsPrivileged(final Subject subject,
final PrivilegedAction action,
final AccessControlContext acc);

public static Object doAsPrivileged(final Subject subject,
final PrivilegedExceptionAction action,
final AccessControlContext acc)
throws PrivilegedActionException;
The doAsPrivileged method behaves exactly as doAs, except that it allows the caller to specify an access control context. Thus it effectively throws away the current AccessControlContext and authorization decisions will be based on the AccessControlContext passed in.

Since the AccessControlContext is set on a per thread basis, different threads within the JVM can assume different identities. The Subject associated with a specific AccessControlContext can be retrieved by using the following method:

public static Subject getSubject(final AccessControlContext acc);

The LoginContext class provides the basic methods used to authenticate Subjects. It also allows an application to be independent of the underlying authentication technologies. The LoginContext consults a configuration that determines the authentication services or LoginModules configured for a particular application. If the application does not have a specific entry, it defaults to the entry identified as “other”.

To support the stackable nature of LoginModules, LoginContext performs authentication in two phases. In the first phase or login phase, it invokes each configured LoginModule to attempt the authentication. If all the necessary LoginModules succeed, then LoginContext enters the second phase where it invokes each LoginModule again to formally commit the authentication process. During this phase the Subject is populated with the authenticated principals and their credentials. If either of the phase fails, then the LoginContext invokes each configured module to abort the entire authentication attempt. Each LoginModule then cleans up any relevant state associated with the authentication attempt.

LoginContext has four constructors that can be used to instantiate it. All of them require the configuration entry name to be passed. In addition the Subject and/or a CallbackHandler can also be passed to the constructors.


The login modules invoked by JAAS must be able to garner information from the caller for authentication. For example the Kerberos login module may require users to enter their Kerberos password for authentication.

The LoginContext allows the application to specify a callbackhandler that the underlying login modules use to interact with users. There are two callback handlers available in Merlin (J2SE 1.4) – one based on the command line and another based on a GUI.


Sun provides an implementation of the UnixLoginModule, NTLoginModule, JNDILoginModule, KeyStoreLoginModule and Krb5LoginModule in Merlin. A smart card based JAAS login module is available from GemPlus [5].

The Kerberos Login Module

The class is Sun’s implementation of a login module for the Kerberos version 5 protocol. Upon successful authentication the Ticket Granting Ticket (TGT) is stored in the Subject’s private credentials set and the Kerberos principal is stored in the Subject’s principal set.

Based on certain configurable options, Krb5LoginModule can also use an existing credentials cache, such as a native cache in the operating system, to acquire the TGT and/or use a keytab file containing the secret key to implicitly authenticate a principal. Both the Solaris and Windows 2000 platforms contain a credentials cache that Krb5LoginModule can use for fetching the TGT. Solaris also contains a system wide keytab file that Krb5LoginModule can use for fetching the secret key. On all platforms, Krb5LoginModule supports options to set the file path to a ticket cache or keytab file of choice. This is useful when third-party Kerberos support is installed and Java integration is desired. Please consult the documentation for Krb5LoginModule to learn about these options. In the absence of a native cache or keytab, the user will be prompted for the password and the TGT obtained from the KDC.

Figure 1 provides a sample JAAS login configuration entry for a client application. In this example, Krb5LoginModule will use the native ticket cache to get the TGT available in it. The authenticated identity will be the identity of the Kerberos principal that the TGT belongs to.

SampleClient { required useTicketCache=true
Figure 1. Sample client configuration entry
Figure 2 provides a sample login configuration entry for a server application. With this configuration, the secret key from the keytab is used to authenticate the principal “nfs/” and both the TGT obtained from the Kerberos KDC and the secret key are stored in the Subject’s private credentials set. The stored key may be used later to validate a service ticket sent by a client (See the section on Java GSS-API.)

SampleServer {
required useKeyTab=true storeKey=true principal=”nfs/”

Figure 2. Sample server configuration entry
In the client code example shown in Figure 3, the configuration entry “SampleClient” will be used by the LoginContext. The TextCallbackHandler class will be used to prompt the user for the Kerberos password. Once the user has logged in, the Subject will be populated with the Kerberos Principal name and the TGT. Thereafter the user can execute code using Subject.doAs passing in the Subject obtained from the LoginContext.

LoginContext lc = null;

try {
lc = new LoginContext(“SampleClient”, new TextCallbackHandler());
// attempt authentication
} catch (LoginException le) {


// Now try to execute ClientAction as the authenticated Subject

Subject mySubject = lc.getSubject();
PrivilegedAction action = new ClientAction();
Subject.doAs(mySubject, action);

Figure 3. Sample client code
ClientAction could be an action that is allowed only for authenticated Kerberos client Principals with a specific value.

Figure 4 shows server side sample code. It is similar to the client code shown in Figure 4 except for the application entry name and the PrivilegedAction.

LoginContext lc = null;

try {
lc = new LoginContext(“SampleServer”, new TextCallbackHandler());
// attempt authentication
} catch (LoginException le) {


// Now try to execute ServerAction as the authenticated Subject

Subject mySubject = lc.getSubject();
PrivilegedAction action = new ServerAction();
Subject.doAs(mySubject, action);

Figure 4. Sample server code
Kerberos Classes

To enable other vendors to provide their own Kerberos login module implementation that can be used with Java GSS-API, three standard Kerberos classes have been introduced in the package. These are KerberosPrincipal for Kerberos principals, KerberosKey for the long-term Kerberos secret key and KerberosTicket for Kerberos tickets. All implementations of the Kerberos login module must use these classes to store principals, keys and tickets in the Subject.


Upon successful authentication of a Subject, access controls can be enforced based upon the principals associated with the authenticated Subject. The JAAS principal based access controls augment the CodeSource access controls of Java 2. Permissions granted to a Subject are configured in Policy, which is an abstract class for representing the system wide access control policy. Sun provides a file based implementation of the Policy class. The Policy class is provider based so that others can provide their own policy implementation.


Generic Security Service API (GSS-API)

Enterprise applications often have varying security requirements and deploy a range of underlying technologies to achieve this. In such a scenario how do we develop a client-server application so that it can easily migrate from one technology to another? The GSS-API was designed in the Common Authentication Technology working group of the IETF to solve this problem by providing a uniform application programming interface for peer to peer authentication and secure communication that insulates the caller from the details of the underlying technology.

The API, described in a language independent form in RFC 2743 [6], accommodates the following security services: authentication, message confidentiality and integrity, sequencing of protected messages, replay detection, and credential delegation. The underlying security technology or “security mechanism” being used, has a choice of supporting one or more of these features beyond the essential one way authentication 1. There are mainly two standard security mechanisms that the IETF has defined: Kerberos V5 [6] and the Simple Public Key Mechanism (SPKM) [8].

The API is designed such that an implementation may support multiple mechanisms simultaneously, giving the application the ability to choose one at runtime. Mechanisms are identified by means of unique object identifier’s (OID’s) that are registered with the IANA. For instance, the Kerberos V5 mechanism is identified by the OID {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) krb5(2)}.

Another important feature of the API is that it is token based. i.e., Calls to the API generate opaque octets that the application must transport to its peer. This enables the API to be transport independent.

Figure 5. A multi-mechanism GSS-API implementation


The Java API for the Generic Security Service was also defined at the IETF and is documented in RFC 2853 [10]. Sun is pursuing the standardization of this API under the Java Community Process (JCP) [11] and plans to deliver a reference implementation with Merlin. Because the JCP is merely endorsing this externally defined API, the IETF assigned package namespace “org.ietf.jgss” will be retained in Merlin.

Sun’s implementation of Java GSS-API, will initially ship with support for the Kerberos V5 mechanism only. Kerberos V5 mechanism support is mandatory for all Java GSS-API implementations in J2SE, although they are free to support additional mechanisms. In a future release, a Service Provider Interface (SPI) will be added so that new mechanisms can be configured statically or even at runtime. Even now the reference implementation in Merlin will be modular and support a private provider SPI that will be converted to public when standardized.

The Java GSS-API framework itself is quite thin, and all security related functionality is delegated to components obtained from the underlying mechanisms. The GSSManager class is aware of all mechanism providers installed and is responsible for invoking them to obtain these components.

The implementation of the default GSSManager that will ship with J2SE is obtained as follows:

GSSManager manager = GSSManager.getInstance();
The GSSManager can be used to configure new providers and to list all mechanisms already present. The GSSManager also serves as a factory class for three important interfaces: GSSName, GSSCredential, and GSSContext. These interfaces are described below with the methods to instantiate their implementations. For a complete API specification, readers are referred to [9] and [11].

Most calls to Java GSS-API throw a GSSException that encapsulate problems that occur both within the GSS-API framework, and within the mechanism providers.

The GSSName Interface

This interface represents an entity for the purposes of Java GSS-API. An implementation of this interface is instantiated as follows:

GSSName GSSManager.createName(String name, Oid nameType)
throws GSSException
For Example:

GSSName clientName = manager.createName(“duke”, GSSName.NT_USER_NAME);
This call returns a GSSName that represents the user principal “duke” at a mechanism independent level. Internally, it is assumed that each supported mechanism will map the generic representation of the user to a more mechanism specific form. For instance a Kerberos V5 mechanism provider might map this name to duke@FOO.COM where FOO.COM is the local Kerberos realm. Similarly, a public key based mechanism provider might map this name to an X.509 Distinguished Name.

If we were referring to a principal that was not a user, but some sort of service, we would indicate that to the Java GSS-API call so that the mechanism knows to interpret it differently.


GSSName serverName = manager.createName(“”,
The Kerberos V5 mechanism would map this name to the Kerberos specific form nfs/ where FOO.COM is the realm of the principal. This principal represents the service nfs running on the host machine

Sun’s implementation of the GSSName interface is a container class. The container class lazily asks the individual providers to perform their mapping when their mechanism is used and then stores each mapped element in a set of principals. In this respect an implementation of GSSName is similar to the principal set stored in a Subject. It may even contain the same elements that are in a Subject’s principal set, but its use is restricted to the context of Java GSS-API.

The name element stored by the Sun Kerberos V5 provider is an instance of a subclass of

The GSSCredential Interface

This interface encapsulates the credentials owned by one entity. Like the GSSName, this interface too is a multi-mechanism container.

Its implementation is instantiated as follows:

GSSCredential createCredential(GSSName name,
int lifetime,
Oid[] desiredMechs,
int usage)

throws GSSException
Here is an example of this call on the client side:

GSSCredential clientCreds =
The GSSManager invokes the providers of the mechanisms listed in the desiredMechs for credentials that belong to the GSSName clientName. Additionally, it imposes the restriction that the credential must be the kind that can initiate outbound requests (i.e., a client credential), and requests a lifetime of 8 hours for it. The returned object contains elements from a subset of desiredMechs that had some credential available to satisfy this criteria. The element stored by the Kerberos V5 mechanism is an instance of a subclass of containing a TGT that belongs to the user.

Credential acquisition on the server side occurs as follows:

GSSCredential serverCreds =
The behavior is similar to the client case, except that the kind of credential requested is one that can accept incoming requests (i.e., a server credential). Moreover, servers are typically long lived and like to request a longer lifetime for the credentials such as the INDEFINITE_LIFETIME shown here. The Kerberos V5 mechanism element stored is an instance of a subclass of containing the secret key of the server.

This step can be an expensive one, and applications generally acquire a reference at initialization time to all the credentials they expect to use during their lifetime.

The GSSContext Interface

The GSSContext is an interface whose implementation provides security services to the two peers.

On the client side a GSSContext implementation is obtained with the following API call:

GSSContext GSSManager.createContext(GSSName peer,
Oid mech,
GSSCredential clientCreds,
int lifetime)
throws GSSException
This returns an initialized security context that is aware of the peer that it must communicate with and the mechanism that it must use to do so. The client’s credentials are necessary to authenticate to the peer.

On the server side the GSSContext is obtained as follows:

GSSContext GSSManager.createContext(GSSCredential serverCreds)
throws GSSException
This returns an initialized security context on the acceptor’s side. At this point it does not know the name of the peer (client) that will send a context establishment request or even the underlying mechanism that will be used. However, if the incoming request is not for service principal represented by the credentials serverCreds, or the underlying mechanism requested by the client side does not have a credential element in serverCreds, then the request will fail.

Before the GSSContext can be used for its security services it has to be established with an exchange of tokens between the two peers. Each call to the context establishment methods will generate an opaque token that the application must somehow send to its peer using a communication channel of its choice.

The client uses the following API call to establish the context:

byte[] GSSContext.initSecContext(byte[] inToken,
int offset,
int len)

throws GSSException
The server uses the following call:

byte[] acceptSecContext(byte[] inToken,
int offset,
int len)

throws GSSException
These two methods are complementary and the input accepted by one is the output generated by the other. The first token is generated when the client calls initSecContext for the first time. The arguments to this method are ignored during that call. The last token generated depends on the particulars of the security mechanism being used and the properties of the context being established.

The number of round trips of GSS-API tokens required to authenticate the peers varies from mechanism to mechanism and also varies with characteristics such as whether mutual authentication or one-way authentication is desired. Thus each side of the application must continue to call the context establishment methods in a loop until the process is complete.

In the case of the Kerberos V5 mechanism, there is no more than one round trip of tokens during context establishment. The client first sends a token generated by its initSecContext() containing the Kerberos AP-REQ message [2]. In order to generate the AP-REQ message, the Kerberos provider obtains a service ticket for the target server using the client’s TGT. The service ticket is encrypted with the server’s long-term secret key and is encapsulated as part of the AP-REQ message. After the server receives this token, it is passed to the acceptSecContext() method which decrypts the service ticket and authenticates the client. If mutual authentication was not requested, both the client and server side contexts would be established, and the server side acceptSecContext() would generate no output.

However, if mutual authentication were enabled, then the server’s acceptSecContext() would generate an output token containing the Kerberos AP-REP [2] message. This token would need to be sent back to the client for processing by its initSecContext(), before the client side context is established.

Note that when a GSSContext is initialized on the client side, it is clear what underlying mechanism needs to be used. The Java GSS-API framework can obtain a context implementation from the appropriate mechanism provider. Thereafter, all calls made to the GSSContext object are delegated to the mechanism’s context implementation. On the server side, the mechanism to use is not decided until the first token from the client side arrives.

Here is a class showing how the client side of an application would be coded. This is the ClientAction class that was executed using the doAs method in Figure 3:

class ClientAction implements PrivilegedAction {

public Object run() {

try {
GSSManager manager = GSSManager.getInstance();
GSSName clientName =
manager.createName(“duke”, GSSName.NT_USER_NAME);
GSSCredential clientCreds =
GSSName peerName =
GSSContext secContext =

// The first input token is ignored
byte[] inToken = new byte[0];

byte[] outToken = null;

boolean established = false;

// Loop while the context is still not established
while (!established) {
outToken =
secContext.initSecContext(inToken, 0, inToken.length);

// Send a token to the peer if one was generated
if (outToken != null)

if (!secContext.isEstablished()) {
inToken = readToken();
established = true;
} catch (GSSException e) {


Figure 6. Sample client using Java GSS-API
The corresponding section of code on the server side running the ServerAction class from Figure 5 is as follows:

class ServerAction implelemts PrivilegedAction {

public Object run() {

try {
GSSManager manager = GSSManager.getInstance();
GSSName serverName =
GSSCredential serverCreds =
GSSContext secContext = manager.createContext(serverCreds);

byte[] inToken = null;
byte[] outToken = null;

// Loop while the context is still not established
while (!secContext.isEstablished()) {
inToken = readToken();
outToken =
secContext.acceptSecContext(inToken, 0, inToken.length);

// Send a token to the peer if one was generated
if (outToken != null)
} catch (GSSException e) {



Figure 7. Sample server using Java GSS-API
Message Protection

Once the security context is established, it can be used for message protection. Java GSS-API provides both message integrity and message confidentiality. The two calls that enable this are as follows:

byte[] GSSContext.wrap(byte[] clearText,
int offset,
int len,
MessageProp properties)
throws GSSException
byte[] unwrap(byte[] inToken,
int offset,
int len,
MessageProp properties)
throws GSSException
The wrap method is used to encapsulate a cleartext message in a token such that it is integrity protected. Optionally, the message can also be encrypted by requesting this through a properties object. The wrap method returns an opaque token that the caller sends to its peer. The original cleartext is returned by the peer’s unwrap method when the token is passed to it. The properties object on the unwrap side returns information about whether the message was simply integrity protected or whether it was encrypted as well. It also contains sequencing and duplicate token warnings.

Credential Delegation

Java GSS-API allows the client to securely delegate its credentials to the server, such that the server can initiate other security contexts on behalf of the client. This feature is useful for single sign-on in a multi-tier environment.

Figure 8. Credential Delegation

The client requests credential delegation prior to making the first call to initSecContext():

void GSSContext.requestCredDeleg(boolean state)
throws GSSException
by setting state to true.
The server receives the delegated credential after context establishment:

GSSCredential GSSContext.getDelegCred() throws GSSException
The server can then pass this GSSCredential to GSSManager.createContext() pretending to be the client.

In the case of the Kerberos V5 mechanism, the delegated credential is a forwarded TGT that is encapsulated as part of the first token sent from the client to the server. Using this TGT, the server can obtain a service ticket on behalf of the client for any other service.


Previously we discussed how an application uses the GSSManager.createCredential() method to populate a GSSCredential object with mechanism specific credentials.The next two sub-sections will focus on how Java GSS-API mechanisms obtain these credentials. The mechanisms do not themselves perform a user login. Instead, the login is performed prior to using Java GSS-API and the credentials are assumed to be stored in some cache that the mechanism provider is aware of. The GSSManager.createCredential() method merely obtains references to those credentials and returns them in a GSS-centric container, the GSSCredential.

In the Java 2 platform we impose the restriction that the credentials cache that Java GSS-API mechanism providers use to obtain these elements must exclusively be the public and private credential sets in the Subject that is on the current access control context.

This model has the advantage that credential management is simple and predictable from the application’s point of view. An application, given the right permissions, can purge the credentials in the Subject or renew them using standard Java API’s. If it purged the credentials, it would be sure that the Java GSS-API mechanism would fail, or if it renewed a time based credential it would be sure that the mechanism would succeed.

Here is the sequence of events relevant to credential acquisition when the Kerberos V5 mechanism is used by the client application in Figures 3 and 6:

The application invokes a JAAS login, which in turn invokes the configured Krb5LoginModule
Krb5LoginModule obtains a TGT (KerberosTicket) for the user either from the KDC or from an existing ticket cache, and stores this TGT in the private credentials set of a Subject
The application retrieves the populated Subject, then calls Subject.doAs/doAsPrivileged which places this Subject on the access control context of the thread executing ClientAction
ClientAction calls the GSSManager.createCredential method, passing it the Kerberos V5 OID in desiredMechs.
GSSManager.createCredential invokes the Kerberos V5 GSS-API provider, asking for a Kerberos credential for initiating security contexts.
The Kerberos provider obtains the Subject from the current access control context, and searches through its private credential set for a valid KerberosTicket that represents the TGT for the user.
The KerberosTicket is returned to the GSSManager which stores it in a GSSCredential container instance to be returned to the caller.
On the server side, when the Kerberos login is successful in step 2, Krb5LoginModule stores the KerberosKey for the server in the Subject in addition to the KerberosTicket. Later on the KerberosKey is retrieved in steps 5 through 7 and used to decrypt the service ticket that the client sends.


The default credential acquisition model for Java GSS-API requires credentials to be present in the current Subject. Typically, the credentials are placed there after a JAAS login by the application.

There might be cases where an application wishes to use Kerberos credentials from outside the Subject. It is recommended that such credentials be read as part of the initial JAAS login, either by configuring Krb5LoginModule to read them, or by writing a custom login module that reads them. However, some applications might have constrains that either prevent them from using JAAS prior to calling Java GSS-API, or force them to use some Kerberos mechanism provider that does not retrieve credentials from the current Subject.

In order to accommodate such cases while still retaining the standard model for others, the system property was added. This system property serves as a boolean where a value of true requires that the standard credential acquisition model be followed, and a value of false permits the provider to use any cache of it choice. The default value of this property (when it is not set) will be assumed to be true.

If there is no valid Kerberos credential in the current Subject, and this property is true, then the Kerberos mechanism throws a GSSException. Setting this property to false does not necessarily mean that the provider has to use a cache other than the current Subject, it only gives the provider the latitude to do so if it wishes.

The Sun provider for the Kerberos V5 GSS-API mechanism always obtains credentials from a Subject. If there are no valid credentials in the current Subject, and this property is set to false, then the provider attempts to obtain new credentials from a temporary Subject by invoking a JAAS login itself. It uses the text callback handler for input/output with the user, and the JAAS configuration entry identified by”other” for the the list of modules and options to use 2. It assumes that one of these modules will be a Kerberos login module. It is possible to configure the modules listed under “other” to read a pre-existing cache so that the user is not unexpectedly prompted for a password in the middle of a Java GSS-API call. The new Subject that is populated by this login is discarded by the Kerberos GSS-API mechanism just as soon as the required credentials are retrieved from it.


An important class of applications that should be able to capitalize on Java single sign-on are applets. For this discussion we assume that the browser JRE has all the required packages or the Java plugin is used with a Merlin JRE installed by the user.

One complication in using applets arises mostly out of the fact that before an applet can use Java GSS-API, it must perform a JAAS login. The main problems with this are (a) an increase in the effort required on the part of the applet developer (b)unnecessary repeated login by the same user each time he or she starts an applet.

A good model to solve this problem would be to have the browser (or the Java plugin) perform a JAAS login once at startup. This would provide a Subject that could always be associated with the access control context whenever any Java code was run. As a result, the applet code would not need to perform a JAAS login prior to using Java GSS-API, and the user login would occur just once.

In the absence of this login functionality in the browser (or Java plugin), applets can still avoid having to perform a JAAS login themselves. To do so, the applets would have to set the system property to false and use a GSS-API mechanism provider that is capable of obtaining credentials from sources other than current Subject. When using a Sun JRE with a Sun Kerberos GSS-API provider, expect the mechanism to perform a JAAS login to obtain new credentials as explained in the previous section. The applet deployer would only need to ensure that the appropriate modules and options are listed in the entry “other” in the JAAS configuration used by the JRE. This saves the applet developer from calling into JAAS API’s directly, but it does not stop the repeated JAAS login that might happen with each applet the user runs. However, by configuring the login modules to read a pre-existing native cache, the deployer can both hide the login from the user, and minimize the overhead in the multiple logins. (See how this is done for the the JAAS configuration entry “SampleClient” in Figure 1.)


The convenience of single sign-on also introduces new risks. What happens if a malicious user gains access to your unattended desktop from where he or she can start applets as you? What happens if malicious applets sign on as you to services that they are not supposed to?

For the former, we have no solution but to caution you against leaving your workstation unlocked! For the latter, we have many authorizations checks in place.

To illustrate some details of the permissions model consider an example where your browser has performed a JAAS login at startup time and associated a Subject with all applets that run in it.

The Subject is protected from rogue applets by means of the class. This permission is checked whenever code tries to obtain a reference to the Subject associated with any access control context.

Even if an applet were given access to a Subject, it needs a to actually read the sensitive private credentials stored in it.

Other kinds of checks are to be done by Java GSS-API mechanism providers as they read credentials and establish security contexts on behalf of the credential’s owner. In order to support the Kerberos V5 mechanism, two new permission classes have been added with the package

ServicePermission(String servicePrinicipal, String action)
DelegationPermission(String principals)
As new GSS-API mechanisms are standardized for J2SE, more packages will be added that contain relevant permission classes for providers of those mechanisms.

The Kerberos GSS-API mechanism permission checks take place at the following points in the program’s execution:

Credential Acquisition

The GSSManager.createCredential() method obtains mechanism specific credential elements from a cache such as the current Subject and stores them in a GSSCredential container. Allowing applets to acquire GSSCredential freely, even if they cannot use them to do much, is undesirable. Doing so leaks information about the existence of user and service principals. Thus, before an application can acquire a GSSCredential with any Kerberos credential elements in it, a ServicePermission check is made.

On the client side, a successful GSSCredential acquisition implies that a TGT has been accessed from a cache. Thus the following ServicePermission is checked:

ServicePermission(“krbtgt/FOO.COM@FOO.COM”, “initiate”);
The service principal krbtgt/FOO.COM@FOO.COM represents the ticket granting service (TGS) in the Kerberos realm FOO.COM, and the action “initiate” suggests that a ticket to this service is being accessed. The TGS service principal will always be used in this permission check at the time of client side credential acquisition.

On the server side, a successful GSSCredential acquisition implies that a secret key has been accessed from a cache. Thus the following ServicePermission is checked:

ServicePermission(“nfs/”, “accept”);
Here the service principal nfs/ represents the Kerberos service principal and the action “accept” suggests that the secret key for this service is being requested.

Context Establishment

An applet that has permissions to contact a particular server, say the LDAP server, must not instead contact a different server such as the FTP server. Of course, the applet might be restricted from doing so with the help of SocketPermission. However, it is possible to use ServicePermission to restrict it from authenticating using your identity, even if the network connection was permitted.

When the Kerberos mechanism provider is about to initiate context establishment it checks the ServicePermission:

ServicePermission(“ftp@FOO.COM”, “initiate”);
This check prevents unauthorized code from obtaining and using a Kerberos service ticket for the principal ftp@FOO.COM.

Providing limited access to specific service principals using this permission is still dangerous. Downloaded code is allowed to communicate back with the host it originated from. A malicious applet could send back the initial GSS-API output token that contains a KerberosTicket encrypted in the target service principal’s long-term secret key, thus exposing it to an offline dictionary attack. For this reason it is not advisable to grant any “initiate” ServicePermission to code downloaded from untrusted sites.

On the server side, the permission to use the secret key to accept incoming security context establishment requests is already checked during credential acquisition. Hence, no checks are made in the context establishment stage.

Credential Delegation

An applet that has permission to establish a security context with a server on your behalf also has the ability to request that your credentials be delegated to that server. But not all servers are trusted to the extent that your credentials can be delegated to them. Thus, before a Kerberos provider obtains a delegated credential to send to the peer, it checks the following permission:

DelegationPermission(” \”ftp@FOO.COM\” \”krbtgt/FOO.COM@FOO.COM\” “);
This permission allows the Kerberos service principal ftp@FOO.COM to receive a forwarded TGT (represented by the ticket granting service krbtgt/FOO.COM@FOO.COM)3.


In this paper we have presented a framework to enable single sign-on in Java. This requires sharing of credentials between JAAS which does the initial authentication to obtain credentials, and Java GSS-API which uses those credentials to communicate securely over the wire. We have focused on Kerberos V5 as the underlying security mechanism, but JAAS’s stackable architecture and Java GSS-API’s multi-mechanism nature allow us to use any number of different mechanisms simultaneously.

The Kerberos login module for JAAS is capable of reading native caches so that users do not have to authenticate themselves beyond desktop login on platforms that support Kerberos. Moreover, the Kerberos V5 mechanism for Java GSS-API allows credentials to be delegated which enables single sign-on in multi-tier environments.

Finally, a number of permissions checks are shown to prevent the unauthorized use of the single-sign on features provided by Kerberos.


We thank Gary Ellison, Charlie Lai, and Jeff Nisewanger for their contribution at each stage of the Kerberos single sign-on project. JAAS 1.0 was implemented by Charlie as an optional package for Kestrel (J2SE 1.3). Gary has been instrumental in designing the permissions model for the Kerberos Java GSS-API mechanism. We are grateful to Bob Scheifler for his feedback on integrating JAAS 1.0 into Merlin and to Tim Blackman for the KeyStoreLoginModule and CallbackHandler implementations. We also thank Bruce Rich, Tony Nadalin, Thomas Owusu and Yanni Zhang for their comments and suggestions. We thank Mary Dageforde for the documentation and tutorials. Sriramulu Lakkaraju, Stuart Ke and Shital Shisode contributed tests for the projects. Maxine Erlund provided management support for the project.


Simplify enterprise Java authentication with single sign-on

July 11, 2009

Does your enterprise run many coexisting Java applications, each requiring authentication in order to access enterprise resources? If so, you’ll probably want to implement single sign-on (SSO) security functionality to make authentication less intrusive for your users. In this article, you’ll learn how to implement SSO using Kerberos and the Java Generic Security Services API (GSS-API). First we’ll cover what SSO means and illustrate its potential applications. Then we’ll explore the sequence of message exchanges that occurs to implement Kerberos-based SSO. Next, we’ll briefly introduce the Java GSS-API and the architecture of a typical Java application that accomplishes SSO using GSS. Finally, we’ll put the pieces together and provide working code examples to demonstrate how Java developers can implement SSO with GSS Kerberos tickets.

What is single sign-on?

Fundamentally, single sign-on authentication means the sharing of authentication data. For instance, many employees of a warehousing company might need to access enterprise resources (database tables, for example) in order to fulfill their job requirements, with different employees needing different resources depending on their job function. An accounts manager may need to access only the accounts-related database tables, while a sales manager may need to access sales-related database tables. In contrast, the CEO of the company may need to access any table in the enterprise’s database.

Obviously, this enterprise needs an authentication mechanism in place that can determine which employee is trying to access a particular resource. Once the enterprise authentication module knows the identity of the employee, an authorization module within the enterprise implementation can check whether the authenticated user has the necessary privileges to access the resource.“>More Here


Identity Management

July 11, 2009

Identity Management is a phrase popular with many analysts and consultants, and is being used to describe a wide range of solutions with many companies publishing long and confusing white papers on the subject. While the term, and the many different solutions it may represent, can cause confusion, there are some important common themes of Identity Management solutions that reflect real requirements. This page covers Isode’s approach to Identity Management, which we describe in terms of a broad directory based solution.