Can initial authentication program

This is the default case. If the User Profile is set to Ignore , the user validation will not be done. The Core Authentication Service contains an Authentication PostProcessing Class attribute which may contain the authentication post-processing class name as its value. It can be executed on either successful or failed authentication or on logout.

More information on this interface can be found in "Implementing Authentication Post Processing". The redirection is based on an order of precedence in which Identity Server looks for redirection based on the authentication method and whether the authentication has been successful or has failed. This order is detailed in the URL redirection portions of the following authentication methods sections.

One more authentication method is a functionality of the Policy Service. This method of authentication allows a user to authenticate to an organization or sub-organization. It is the default method of authentication for Identity Server. The authentication method for an organization is set by registering the Core Authentication Service to the organization and defining the Organization Authentication Configuration attribute.

The organization of a request for authentication is determined from the following, in order of precedence:. After calling the correct organization, the authentication module s to which the user will authenticate are retrieved from the Organization Authentication Configuration attribute in the Core Authentication Service.

The login URLs used to specify and initiate organization-based authentication are:. If there is no defined parameter, the organization will be determined from the server host and domain specified in the login URL. Upon a successful or failed organization-based authentication, Identity Server looks for information on where to redirect the user. Following is the order of precedence in which the application will look for this information. The redirection URL for successful organization-based authentication is detemined by checking the following places in order of precedence:.

The redirection URL for failed organization-based authentication is detemined by checking the following places in the following order:.

This method of authentication allows a user to authenticate to a role either static or filtered within an organization or sub-organization. The Authentication Configuration Service must first be registered to the organization before it can be registered as an instance to the role.

For authentication to be successful, the user must belong to the role and they must authenticate to each module defined in the Authentication Configuration Service instance configured for that role. For each instance of role-based authentication, the following attributes can be specified:. After calling the correct role, the authentication module s to which the user will authenticate are retrieved from the Authentication Configuration Service instance defined for the role.

The login URLs used to specify and initiate this role-based authentication are:. If there is no configured org Parameter , the organization to which the role belongs will be determined from the server host and domain specified in the login URL itself. Upon a successful or failed role-based authentication, Identity Server looks for information on where to redirect the user. The redirection URL for successful role-based authentication is detemined by checking the following places in the following order:.

The redirection URL for failed role-based authentication is detemined by checking the following places in the following order:. This method of authentication allows a user to authenticate to a specific service or application registered to an organization or sub-organization.

The service is configured as a Service Instance within the Authentication Configuration Service and is associated with an Instance Name. For authentication to be successful, the user must authenticate to each module defined in the Authentication Configuration Service instance configured for the service. For each instance of service-based authentication, the following attributes can be specified:.

After calling the service, the authentication module s to which the user will authenticate are retrieved from the Authentication Configuration Service instance defined for the service. The login URLs used to specify and initiate this service-based authentication are:. If there is no configured org parameter, the organization will be determined from the server host and domain specified in the login URL itself.

Upon a successful or failed service-based authentication, Identity Server looks for information on where to redirect the user. The redirection URL for successful service-based authentication is detemined by checking the following places in the following order:. The redirection URL for failed service-based authentication is detemined by checking the following places in the following order:.

This method of authentication allows a user to authenticate to an authentication process configured specifically for them. For authentication to be successful, the user must authenticate to each module defined. After calling the correct user, the authentication module s to which the user will authenticate are retrieved from the User Authentication Configuration instance defined for them.

On receiving a request for user-based authentication, the Authentication Service first verifies that the user is a valid user and then retrieves the Authentication Configuration data for them.

In the case where there is more then one valid user profile associated with the value of the user Login URL parameter, all profiles must map to the specified user.

The User Alias Attribute iplanet-am-user-alias-list in the User profile is where other profiles belonging to the user can be defined. If mapping fails, the user is denied a valid session. The exception would be if one of the users is a Super Admin whereby the user mapping validation is not done and the user is given Super Admin rights. Upon a successful or failed user-based authentication, Identity Server looks for information on where to redirect the user.

The redirection URL for successful user-based authentication is detemined by checking the following places in order of precedence:. The redirection URL for failed user-based authentication is detemined by checking the following places in the following order:.

This method of authentication allows an administrator to specify the security level of the modules to which identities can authenticate. Each authentication module has a separate Authentication Level attribute and the value of this attribute can be defined as any valid integer. With Authentication Level-based authentication, the Authentication Service displays a module login page with a menu containing the authentication modules that have authentication levels equal to or greater then the value specified in the Login URL parameter.

Users can select a module from the presented list. Figure illustrates this list of modules based on authentication level. Once the user selects a module, the remaining process is based on Module-based Authentication as discussed on. After calling the login screen with the relevant list of modules, the user must choose one with which to authenticate.

The login URLs used to specify and initiate authentication level-based authentication are:. If there is no configured org parameter, the organization to which the user belongs will be determined from the server host and domain specified in the login URL itself.

Upon a successful or failed authentication level-based authentication, Identity Server looks for information on where to redirect the user. The redirection URL for successful authentication level-based authentication is detemined by checking the following places in order of precedence:.

The redirection URL for failed authentication level-based authentication is detemined by checking the following places in the following order:.

This method of authentication allows a user to specify the module to which they will authenticate. The specified module must be registered to the organization or sub-organization that the user is accessing.

On receiving this request for module-based authentication, the Authentication Service verifies that the module is correctly configured as noted, and if the module is not defined, the user is denied access. The login URLs used to specify and initiate module-based authentication are:.

If there is no configured org paramter, the organization to which the user belongs will be determined from the server host and domain specified in the login URL itself. Upon a successful or failed module-based authentication, Identity Server looks for information on where to redirect the user. The redirection URL for successful module-based authentication is detemined by checking the following places in order of precedence:. The redirection URL for failed module-based authentication is detemined by checking the following places in the following order:.

They include the following:. The Authentication Service provides a feature where a user will be locked out from authenticating after n failures. This feature is turned off by default, but can be enabled using the Identity Server console. The Core Authentication Service contains attributes for enabling and customizing this feature including but not limited to :.

Email notifications are sent to administrators regarding any account lockouts. Account locking activities are also logged. Identity Server supports two types of account locking are supported: Physical Locking and Memory Locking.

These are defined in the next sections. This is the default locking behavior for Identity Server. Aliased users can be verified by adding iplanet-am-user-alias-list to the Alias Search Attribute Name field in the Core Authentication Service.

That said, if an aliased user is locked out, the actual LDAP profile to which the user is aliased will be locked. Memory locking is enabled by changing the Login Failure Lockout Duration attribute to a value greater then 0. The account will be unlocked after the time period has passed.

Following are some special considerations when using the memory locking feature:. One or more authentication modules can be configured so a user must pass authentication credentials to all of them. This is referred to as authentication chaining. Module chaining is configured under the Authentication Configuration Service.

Each registered module is assigned one of the following four values:. Once authentication to all modules in the chain is successful, control is returned to the Authentication Service from the JAAS framework which validates all the user IDs used to authenticate and maps them to one user.

A valid session token is issued to the user if all the maps are correct; if not, the user is denied a valid session token. The following properties would represent the single authenticated user to which the other users are aliased:.

In authentication chaining, if all user IDs do not map to one single user, the failure redirection URL will be picked up from the last failed authentication module or none if all individual modules succeed with different user ID. If case of user-based authentication, no matter what user ID is given in the authentication page, the failure redirection URL will always be picked up from the user parameter in the login URL.

FQDN mapping is enabled by modifying the com. The format for specifying this property is:. The value invalid-name would be a possible invalid FQDN host name that may be typed by the user, and valid-name would be the actual host name to which the filter will redirect the user. Any number of mappings can be specified as illustrated in Code Example as long as they conform to the stated requirements.

If this property is not set, the user would be sent to the default server name configured in the com. This property can be used for creating a mapping for more than one host name which may be the case if applications hosted on a server are accessible by more than one host name. This property can also be used to configure Identity Server to not take corrective action for certain URLs.

For example, if no redirect is required for users who access applications by using an IP address, this feature can be implemented by specifying a map entry such as:.

If more than one mapping is defined, ensure that there are no overlapping values in the invalid FQDN name. Failing to do so may result in the application becoming inaccessible.

A persistent cookie is one that continues to exist after the web browser is closed, allowing a user to login with a new browser session without having to reauthenticate. The name of the cookie is defined by the com. The cookie value is a 3DES-encrypted string containing the userDN, organization name, authentication module name, maximum session time, idle time, and cache time.

To enable persistent cookies:. Once the user authenticates using this URL, if the browser is closed, they can open a new browser window and will be redirected to the console without reauthentication.

This will work until the time defined in Step 2 elapses. As a form of failover or to configure multiple values for an attribute when the Identity Server console only provides one value field, an administrator can define multiple LDAP authentication module configurations under one organization.

For example, one organization can define a search through LDAP servers for authentication in two different domains or it can configure multiple user naming attributes in one domain. For the latter, which has only one text field in the console, if a user is not found using the primary search criteria, the LDAP module will then search using the second scope.

Following are the steps to configure additional LDAP configurations. Any or all attributes can be defined for this file. Code Example is an example of a subconfiguration file that includes values for all attributes available to the LDAP authentication configuation.

The value of this attribute is formatted in bold in Code Example There is a sample available for multi-LDAP configuration. Instructions can be found in Readme. The Authentication Service allows for the upgrading of a valid session token based on a second, successful authentication performed by the same user to one organization. If a user with a valid session token attempts to authenticate to a resource secured by his current organization and this second authentication request is successful, the session is updated with the new properties based on the new authentication.

If the user with a valid session attempts to authenticate to a resource secured by a different organization, the user will receive a message asking whether they would like to authenticate to the new organization. The user can, at this point, maintain the current session or attempt to authenticate to the new organization. Successful authentication will result in the old session being destroyed and a new one being created.

During session upgrade, if a login page times out, redirection to the original success URL will occur. Timeout values are determined based on:. The values of com. An Administrator can write username or password validation logic suitable to their organization, and plug this into the Authentication Service.

Before authenticating the user or changing the password, Identity Server will invoke this plugin. If the validation is successful, authentication continues; if it fails, an authentication failed page will be thrown. The plugin extends the com. Information on this SDK can be found in the com. The steps below document how to write and configure a validation plugin for Identity Server.

ModuleProperties is the root element of the authentication module configuration file. It must contain at least one Callbacks sub-element.

The required XML attributes of ModuleProperties are moduleName which takes a value equal to the name of the module and version which takes a value equal to the version number of the authentication module configuration file itself. Note the ModuleProperties element on the first line of code. The Callbacks element is used to define the information a module needs to gather from the client requesting authentication.

Each Callbacks element signifies a separate screen that can be called during the authentication process. The required XML attributes of Callbacks are:. The first asks the requestor for a name and password. The second is an optional screen that allows the requestor to change their password. The final screen sends a message informing the user that it is time to reset their password. The Callbacks element can also be used for error handling.

An error message can be sent to the user interface using the header and error attributes and formatting the element as:. Please contact the service desk to reset your password.

The NameCallback element is used to request data from the user; for example, a user identification. It can contain one sub-element, Prompt, which defines the text that precedes the input field.

The optional XML attributes are isRequired and attribute. A value of true displays an asterisk next to the text defined in Prompt. The PasswordCallback element is used to request password data to be entered by the user.

The ChoiceCallback element is used when the application user must choose from multiple values. It can contain two sub-elements: Prompt or ChoiceValues. Prompt defines the text that precedes the input field. ChoiceValues defines the values from which the user may choose.

It defines whether the user can choose a number of values or only one from the available choices. In future versions of Identity Server, this element will support additional features. It can contain one sub-element, OptionValues , which provides a list of text information. There are no XML attributes. When a custom authentication module XML service file is configured without the ConfirmationCallback , button properties are picked up from the global i18n authentication properties file, amAuthUI.

The Prompt element is used to set the text that will display beside a text input field on the browser screen. It has no sub-elements or XML attributes. The ChoiceValues element provides a list of choices from which the user can select. It must contain at least one sub-element of the type ChoiceValue which defines one choice.

ChoiceValue must contain the sub-element Value. The OptionValues element provides a list of text information for buttons that need to be rendered on the login screen. It must contain at least one sub-element of the type OptionValue which defines one button text value. OptionValue must contain the sub-element Value.

The Value element is used by the client to return a value provided by the requestor back to the Identity Server. The structure of these messages is defined in the remote-auth. The Identity Server console receives these XML-based messages which provide definitions to initiate the collection of credentials and perform authentication.

An explanation of the elements defined by the remote-auth. More information can be found in the file itself. AuthContext is the root element of the XML-based message.

It must contain a Request or Response sub-element. The Request element is used by the client to initialize and pass user credentials to the Authentication Service.

The required XML attribute of Request is authIdentifier which takes a value equal to a unique random number set by the Authentication Service that is used to keep track of the authentication session. Table shows the Request sub-elements and the possible Responses for each. The NewAuthContext element initiates the authentication process by initializing the Authentication Service and creating a session token for each request.

It contains no sub-elements. The required XML attribute of NewAuthContext is orgName which takes a value equal to the name of the organization or sub-organization for which the process is being defined. The QueryInformation element is used by the remote client to get information about the authentication modules supported by the Identity Server or the organization.

The required XML attribute of QueryInformation is requestedInformation which takes a value equal to the defined authentication module plug-ins configured for the organization or sub-organization. The Login element is used to initialize the authentication session. The IndexTypeNamePair element can be used to specify the defined authentication type and value.

It has no required XML attributes. It has a Callbacks sub-element and no required XML attributes. The Logout element is used by the remote client to indicate that user wants to logout. It has an Empty sub-element and no required XML attributes. The Abort element is used by the remote client to indicate that the user wants to end the login process.

It has an Empty sub-element and no XML attributes. The Response element is used by the Authentication Service to ask the remote client to gather user credentials or to inform the remote client on the success or failure of the login as well as any errors that might have occurred. The required XML attribute of Response is authIdentifier which takes a value equal to a unique random number set by the Authentication Service and used to keep track of the authentication session.

The QueryResult element is used by Identity Server to send query information requested by the remote client. It must contain a Value sub-element. The required XML attribute of QueryResult is requestedInformation which takes a value equal to the authentication module plug-ins configured for an organization or sub-organization.

The GetRequirements element is used by the Identity Server to request authentication credentials from the client. The LoginStatus element is used by the Identity Server to indicate the status of the authentication process. It will have an Empty sub-element if a Subject or Exception sub-element is not defined.

If the LoginStatus is successful, the sub-element Subject will be returned with the authenticated user names. The attribute ssoToken will have the session token status set to inprogress when a new AuthContext is created, to success when a login has been successful, to failed when a login has not been successful and completed when the user logs out.

The Exception element is used by the Identity Server to inform the client about an exception that occurred during the login process. It has an Empty sub-element and four optional XML attributes: message which takes a value equal to that of the exception message, tokenId which takes a value equal to that of the user ID of the failed authentication, errorCode which takes a value equal to that of the error message code and templateName which takes a value equal to the name of the JSP template which will be used for this particular exception.

The IndexTypeNamePair element identifies the defined authentication method that will be used to validate the client. It has the IndexName sub-element. The required XML attribute is IndexType which takes a value equal to that of the generic level at which the authentication method has been defined: authLevel , role , user , moduleInstance and service.

See "Authentication Methods" for more information. The authentication method can be defined at the organization level, the role level, the user level, the authentication-level level or the service level, or the module level. The IndexType attribute defines authLevel , role , user , moduleInstance and service. The IndexName element takes a value equal to that of the name of the level at which the authentication method has been defined. For example, if IndexType is user or role then, IndexName might be joe or administrator , respectively.

IndexName has no sub-elements and no XML attributes. The Subject element identifies a collection of one or more identities. It has no sub-elements and no XML attributes. The Callbacks element is used to request and transfer user credentials between the remote client and Identity Server. Identity Server constructs callback objects for information gathering.

The client program collects the credentials by prompting the user and returns the callback objects with the required data. The required XML attribute is length which takes a value equal to that of a token. The NameCallback element is used to obtain the name of the user or service that is requesting authentication. It may contain one or more of the following sub-elements: Prompt or Value. The PasswordCallback element is used to obtain the password of the user or service that is requesting authentication.

The required XML attribute is echoPassword which takes a value of true or false. The default value of false indicates that there will be no password confirmation. The ChoiceCallback element is used when the user must choose from a selection of values. The default value of false indicates that the user can not choose more than one from the selection.

The ConfirmationCallback element is used by the Identity Server to request a confirmation from the user. The TextInputCallback element is used to get text information from the user. There are no required XML attributes. The TextOutputCallback element is used when the user must choose from a selection of values. It may contain the sub-element Value. The required XML attribute is messageType which defines the type of message, either information, warning or the default, error. It must contain the Locale sub-element.

The default value is false which indicates that this page is not an error page. The CustomCallback element is used to define user-defined callbacks. It may contain the AttributeValuePair sub-element. The ModuleName element is takes a value equal to the name of the authentication module. It contains no sub-elements and no XML attributes.

The HeaderValue element is takes a value equal to the header that will be displayed. The ImageName element is takes a value equal to the name of the image to be displayed. The PageTimeOutValue element is the page time-out value in seconds. The TemplateName element is takes a value equal to the name of the template to be rendered. The AttributeValuePair element contains the attribute and values for a Callback.

It must contain the Attribute sub-element and it can contain the Value sub-element. The Attribute element defines the Callback parameter. The required XML attribute is name which takes a value equal to the name of the Callback parameter. The Value element is used by the remote client to return a value, provided by the user or service , back to the Identity Server.

It must contain at least one Value sub-element. The Prompt element is used by Identity Server to request the remote client to display the prompt. It contains no sub-elements and there are no required XML attributes. The Locale element contains the value of the locale that will be used for authentication.

The optional XML attributes are language which represents the language code , country which represents the country code and variant which represents the variant code. The ChoiceValues element provides a list of choices. It must contain at least one the ChoiceValue sub-element. The ChoiceValues element provides a single choice. The required XML attribute is isDefault which takes a value of yes or no. The default value of no specifies if the value has to be selected by default when displayed.

The SelectedValues element provides a list of values selected by the user. The SelectedValue element provides a value selected by the user. The SelectedValues element provides a single user-defined option value.

The DefaultOptionValue element is the default option value. The default value depends on whether user-defined values or predefined values are used in the callback. If user-defined values are used, the default value will be an index in the OptionValues element; if predefined, it will be one of the predefined option values.

The Authentication Service allows an organization to write and plug-in custom modules for authentication providers not currently implemented by Identity Server. The first step is to code the module in Java using the Service Programming Interfaces. Instructions on how to do this and which classes to use can be found in "Implementing A Custom Authentication Module".

The following steps describe the procedure to integrate a custom authentication module into the Identity Server deployment. In detailing this procedure, it also explains what files are needed in order to make the integration work.

For information on how to implement a custom module, see "Service Programming Interfaces". An authentication module configuration file specifies, at a minimum, the information required from an identity user, service, or application for authentication.

The required credentials might include, but are not limited to, user name and password. Based on this file, the Authentication Service will dynamically generate the login screens. Additional information on the file itself can be found in "Authentication Module Configuration Files".

Information on how to create it can be found in "Configuring The Authentication Module". Creating the authentication module configuration file first allows time to plan the module requirements as each Callbacks Element defined corresponds to a login state.

When an authentication process is invoked, a Callback is generated from the module for each state. The localization properties file defines language-specific screen text for the attribute names of the module. Information on this file can be found in "Configuring Authentication Localization Properties". Additional information on how to modify its contents can be found in "Configuring Console Localization Properties" of Chapter 6, "Service Management," in this manual.

The name of the XML service file follows the format amAuth modulename. Information on the steps to create and import an XML service file can be found in Chapter 6, "Service Management," in this manual. The new module needs to be recognized by the Identity Server framework. The authentication module configuration file is an XML file that defines the requirements that each module seeks for authentication.

In other words, this file defines the screens that a user might see when directed to authenticate i. So to distinguish Kerberos clients from clients of other services, we use the term principal to indicate such an entity.

Note that a Kerberos principal can be either a user or a server. We describe the naming of Kerberos principals in a later section. Service vs. We use service as an abstract specification of some actions to be performed.

A process which performs those actions is called a server. At a given time, there may be several servers usually running on different machines performing a given service. Key, Private Key, Password. Kerberos uses private key encryption. Each Kerberos principal is assigned a large number, its private key, known only to that principal and Kerberos. In the case of a user, the private key is the result of a one-way function applied to the user's password.

We use key as shorthand for private key. Unfortunately, this word has a special meaning for both the Sun Network File System and the Kerberos system.

We explicitly state whether we mean NFS credentials or Kerberos credentials, otherwise the term is used in the normal English language sense. Master and Slave. It is possible to run Kerberos authentication software on more than one machine.

However, there is always only one definitive copy of the Kerberos database. The machine which houses this database is called the master machine, or just the master. Other machines may possess read-only copies of the Kerberos database, and these are called slaves. In a non-networked personal computing environment, resources and information can be protected by physically securing the personal computer.

In a timesharing computing environment, the operating system protects users from one another and controls resources. In order to determine what each user is able to read or modify, it is necessary for the timesharing system to identify each user.

This is accomplished when the user logs in. In a closed environment where all the machines are under strict control, one can use the first approach. When the organization controls all the hosts communicating over the network, this is a reasonable approach. In a more open environment, one might selectively trust only those hosts under organizational control. In this case, each host must be required to prove its identity. The rlog-in and rsh programs use this approach.

In those protocols, authentication is done by checking the Internet address from which a connection has been established. In the Athena environment, we must be able to honor requests from hosts that are not under organizational control. Users have complete control of their workstations: they can reboot them, bring them up standalone, or even boot off their own tapes. The server must also prove its identity. It is not sufficient to physically secure the host running a network server; someone elsewhere on the network may be masquerading as the given server.

Our environment places several requirements on an identification mechanism. First, it must be secure. Circumventing it must be difficult enough that a potential attacker does not find the authentication mechanism to be the weak link. Someone watching the network should not be able to obtain the information necessary to impersonate another user. Second, it must be reliable. Access to many services will depend on the authentication service. If it is not reliable, the system of services as a whole will not be.

Third, it should be transparent. Ideally, the user should not be aware of authentication taking place. Finally, it should be scalable. Many systems can communicate with Athena hosts. Not all of these will support our mechanism, but software should not break if they did.

Kerberos is the result of our work to satisfy the above requirements. The security of Kerberos relies on the security of several authentication servers, but not on the system from which users log in, nor on the security of the end servers that will be used.

Authentication is a fundamental building block for a secure networked environment. If, for example, a server knows for certain the identity of a client, it can decide whether to provide the service, whether the user should be given special privileges, who should receive the bill for the service, and so forth.

In other words, authorization and accounting schemes can be built on top of the authentication that Kerberos provides, resulting in equivalent security to the lone personal computer or the timesharing system. Kerberos is a trusted third-party authentication service based on the model presented by Needham and Schroeder. It is trusted in the sense that each of its clients believes Kerberos' judgement as to the identity of each of its other clients to be accurate. Time stamps large numbers representing the current date and time have been added to the original model to aid in the detection of replay.

Replay occurs when a message is stolen off the network and resent later. For a more complete description of replay, and other issues of authentication, see Voydock and Kent.

Kerberos keeps a database of its clients and their private keys. The private key is a large number known only to Kerberos and the client it belongs to. In the case that the client is a user, it is an encrypted password. Network services requiring authentication register with Kerberos, as do clients wishing to use those services. The private keys are negotiated at registration. Because Kerberos knows these private keys, it can create messages which convince one client that another is really who it claims to be.

Kerberos also generates temporary private keys, called session keys, which are given to two clients and no one else. A session key can be used to encrypt messages between two parties. Kerberos provides three distinct levels of protection. The application programmer determines which is appropriate, according to the requirements of the application.

For example, some applications require only that authenticity be established at the initiation of a network connection, and can assume that further messages from a given network address originate from the authenticated party. Our authenticated network file system uses this level of security.

Other applications require authentication of each message, but do not care whether the content of the message is disclosed or not. For these, Kerberos provides safe messages. Yet a higher level of security is provided by private messages, where each message is not only authenticated, but also encrypted. Private messages are used, for example, by the Kerberos server itself for sending passwords over the network.

The Athena implementation comprises several modules see Figure 1. The Kerberos applications library provides an interface for application clients and application servers. It contains, among others, routines for creating or reading authentication requests, and the routines for creating safe or private messages.

The encryption library implements those routines. Several methods of encryption are provided, with tradeoffs between speed and security.

In CBC, an error is propagated only through the current block of the cipher, whereas in PCBC, the error is propagated throughout the message. This renders the entire message useless if an error occurs, rather than just a portion of it. The encryption library is an independent module, and may be replaced with other DES implementations or a different encryption library.

Another replaceable module is the database management system. Other database management libraries could be used as well. The Kerberos database needs are straightforward; a record is held for each principal, containing the name, private key, and expiration date of the principal, along with some administrative information. The expiration date is the date after which an entry is no longer valid. It is usually set to a few years into the future at registration. Other user information, such as real name, phone number, and so forth, is kept by another server, the Hesiod nameserver.

This way, sensitive information, namely passwords, can be handled by Kerberos, using fairly high security measures; while the non-sensitive information kept by Hesiod is dealt with differently; it can, for example, be sent unencrypted over the network. The Kerberos servers use the database library, as do the tools for administering the database. The administration server or KDBM server provides a read-write network interface to the database. The client side of the program may be run on any machine on the network.

The server side, however, must run on the machine housing the Kerberos database in order to make changes to the database. The authentication server or Kerberos server , on the other hand, performs read-only operations on the Kerberos database, namely, the authentication of principals, and generation of session keys.

Since this server does not modify the Kerberos database, it may run on a machine housing a read-only copy of the master Kerberos database. Database propagation software manages replication of the Kerberos database. It is possible to have copies of the database on several different machines, with a copy of the authentication server running on each machine. Each of these slave machines receives an update of the Kerberos database from the master machine at given intervals.

Finally, there are end-user programs for logging in to Kerberos, changing a Kerberos password, and displaying or destroying Kerberos tickets tickets are explained later on. Part of authenticating an entity is naming it.

The process of authentication is the verification that the client is the one named in a request. What does a name consist of? In Kerberos, both users and servers are named. As far as the authentication server is concerned, they are equivalent. A name consists of a primary name, an instance, and a realm, expressed as name. The primary name is the name of the user or the service. The instance is used to distinguish among variations on the primary name.

For users, an instance may entail special privileges, such as the "root" or "admin" instances. For services in the Athena environment, the instance is usually the name of the machine on which the server runs. For example, the rlog-in service has different instances on different hosts: rlog-in.

A Kerberos ticket is only good for a single named server. As such, a separate ticket is required to gain access to different instances of the same service. The realm is the name of an administrative entity that maintains authentication data.

For example, different institutions may each have their own Kerberos machine, housing a different database. They have different Kerberos realms. Realms are discussed further in section 8. This section describes the Kerberos authentication protocols. The following abbreviations are used in the figures.

As mentioned above, the Kerberos authentication model is based on the Needham and Schroeder key distribution protocol. To do this, a ticket is presented to the server, along with proof that the ticket was originally issued to the user, not stolen.

There are three phases to authentication through Kerberos. In the first phase, the user obtains credentials to be used to request access to other services. In the second phase, the user requests authentication for a specific service. In the final phase, the user presents those credentials to the end server.

There are two types of credentials used in the Kerberos authentication model: tickets and authenticators. Both are based on private key encryption, but they are encrypted using different keys. A ticket is used to securely pass the identity of the person to whom the ticket was issued between the authentication server and the end server. A ticket also passes information that can be used to make sure that the person using the ticket is the same person to which it was issued.

The authenticator contains the additional information which, when compared against that in the ticket proves that the client presenting the ticket is the same one to which the ticket was issued.

A ticket is good for a single server and a single client. It contains the name of the server, the name of the client, the Internet address of the client, a time stamp, a lifetime, and a random session key. This information is encrypted using the key of the server for which the ticket will be used.

Once the ticket has been issued, it may be used multiple times by the named client to gain access to the named server, until the ticket expires. Note that because the ticket is encrypted in the key of the server, it is safe to allow the user to pass the ticket on to the server without having to worry about the user modifying the ticket see Figure 3.

Unlike the ticket, the authenticator can only be used once. A new one must be generated each time a client wants to use a service. This does not present a problem because the client is able to build the authenticator itself. This certificate can be used to sign identity information that is being sent from the identity provider to the service provider so that the service provider knows it is coming from a trusted source.

When the user tries to access a different website, the new website would have to have a similar trust relationship configured with the SSO solution and the authentication flow would follow the same steps. Tokens must be digitally signed for the token receiver to verify that the token is coming from a trusted source.

The certificate that is used for this digital signature is exchanged during the initial configuration process. There are many reasons why SSO can improve security. A single sign-on solution can simplify username and password management for both users and administrators. Users no longer have to keep track of different sets of credentials and can simply remember a single more complex password. SSO often enables users to just get access to their applications much faster. SSO can also cut down on the amount of time the help desk has to spend on assisting users with lost passwords.

Administrators can centrally control requirements like password complexity and multi-factor authentication MFA. Administrators can also more quickly relinquish login privileges across the board when a user leaves the organization. Single Sign-On does have some drawbacks. For example, you might have applications that you want to have locked down a bit more. For this reason, it would be important to choose an SSO solution that gives you the ability to, say, require an additional authentication factor before a user logs into a particular application or that prevents users from accessing certain applications unless they are connected to a secure network.

The specifics on how an SSO solution is implemented will differ depending on what exact SSO solution you are working with. But no matter what the specific steps are, you need to make sure you have set clear objectives and goals for your implementation. Make sure you answer the following questions:. With password vaulting, you may have the same username and password, but they need to be entered each time you move to a different application or website.

The password vaulting system is simply storing your credentials for all the different applications and inserting them when necessary. There is no trust relationship set up between the applications and the password vaulting system. That includes cloud applications as well as on-prem applications, often available through an SSO portal also called a login portal. In many cases, the difference might simply be in the way the companies have categorized themselves.

A piece of software suggests something that is installed on-premise. It is usually designed to do a specific set of tasks and nothing else.