Skip to Main Content
Return to Navigation

Implementing Kerberos as the Desktop Single Signon Solution

This section presents an overview of a Kerberos-PeopleSoft integration, presents considerations for securing Kerberos tokens across the enterprise, and then discusses how to:

Understanding Implementing Kerberos Authentication in PeopleSoft Systems

PeopleTools delivers a Kerberos Software Development Kit (SDK) that enables you to configure your PeopleSoft web and application servers to accept Kerberos authentication from Microsoft Active Directory, an LDAP version 3 compliant directory server. The SDK includes a servlet filter and also provides Java source code, which makes it possible for you to create more extensive custom single-signon features, such as support for multi-factor authentication or to consume custom or other authentication environment tokens.

A topic in this documentation describes how to set up Microsoft Active Directory.

The Kerberos SDK is a proof of concept that was developed and tested in the Microsoft Windows environment. To implement Kerberos authentication in non-Windows environments, you must customize the Kerberos SDK source code.

Understanding Kerberos-PeopleSoft Integration

Kerberos is a network protocol that uses secret key cryptography to provide authentication between clients and servers. The Kerberos authentication protocol enables mutual authentication between clients and servers before secure network connections are established. Kerberos establishes trust between a client and server by using a third party intermediary called the Key Distribution Center (KDC). The KDC stores a secret key (password) for every client and server on the network. Clients and servers authenticate each other by exchanging tickets, which represent the clients' network credentials. When a client wants to access a server, the client first authenticates against the KDC and requests a client-to-server ticket for that server. The client then presents that ticket to the server, which validates the credentials and then processes the client’s request.

In Kerberos-PeopleSoft single signon integrations, the Kerberos server handles HTTP requests. While Kerberos was not specifically designed to operate over HTTP, tokens can nonetheless be wrapped within HTTP headers according to the Simple Protected Negotiate (SPNEGO) protocol. In a Kerberos-PeopleSoft implementation, you must configure the web server to:

  1. Accept the HTTP-wrapped Kerberos tokens that are sent by the client.

  2. Forward the user credentials on to the application server for signon.

Note: The Kerberos protocol assumes that transactions between clients and servers take place on an open network where most clients and many servers are not physically secure, and packets traveling along the network can be monitored and modified freely. In such a situation, Kerberos authentication prevents hackers, who can appear to be either a client or a server, from accessing , viewing , and manipulating communications between legitimate clients and servers.

When implementing Kerberos desktop single signon, you configure your directory server to act as the KDC. All clients and servers must authenticate against the KDC before they can communicate securely with each other. Clients authenticate when a user signs in using network credentials from a laptop or desktop machine. Servers, on the other hand, generally authenticate as a different user than the one running the server process. Because of this, you must create a server user account in your directory.

A user's credentials must pass to the server machine; you do this by using a keytab file. The keytab file stores the name and encrypted password of the server user account. The use of the keytab file enables a server to automatically authenticate against the KDC without prompting for the password or storing it as plaintext. You also must map the server user’s credentials to a Service Principal Name (SPN) that matches the website that the server hosts. For example, if a browser requests a client-to-server ticket for www.example.com, it asks the KDC for a ticket to a service principal named HTTP/www.example.com@example.com. You must create the mapping between this SPN and the server user.

Note: PeopleSoft's Kerberos authentication implementation supports only Microsoft Active Directory as an LDAP version 3 directory server.

The PeopleSoft Web Server KerberosSSOFilter Servlet

The PeopleSoft web server requests authentication from the client and then forwards the client credentials to the application server. This process is encapsulated in the KerberosSSOFilter servlet filter, which you attach to the PeopleSoft portal servlet. Servlet filters are intermediaries between the portal servlet and the client. Filters can:

  • Pass messages through unchanged.

  • Modify message contents.

  • Stop messages entirely.

Image: KerberosSSOFilter authentication process flow

The following diagram illustrates the request and response flow between the client, the KerberosSSOFilter, and the portal servlet.

KerberosSSOFilter authentication process flow

This table describes the requests and responses between the client, the KerberosSSOFilter and the web server.

Request/Response

Description

1 REQ

Request from client (who may be authenticated, unauthenticated, or providing authentication)

2 RES

Response from KerberosSSOFilter requesting authentication

3 REQ + header

Request along with KRB_HEADER (Authentication) header which contains the authenticated user

4 RES

Response from the Portal Servlet (likely forwarded from the application server)

5 REQ

Request from client, unmodified because the client has a session 6

6 REQ - token

Request from client with Kerberos token removed because authentication of at token failed

7 REQ

Request from client, unmodified because the request was a POST

The filter first checks to see if the client request (1) has a valid session id. If it does, then the client is already authenticated and no further action is required (5). If not, the filter checks the request’s headers for a Kerberos token. This token is then validated using the server’s credentials. If the token is valid, the authenticated username is added to the request in a special header, KRB_USER (3). The application server can then retrieve the username from this header, once it receives the request.

If the token is invalid, the token header is removed, making it appear to the servlet (and eventually the application server) as if no ticket exchange occurred (6). If no Kerberos token is present, then the filter must request authentication (2). Before doing so, it checks if the request is a POST. POST requests are always passed through to the Servlet (7), because the client browser will not resend POST parameters along with the authentication information. In addition, POST is used during regular web-based sign in, and performing single signon simultaneously with this is redundant and not a good practice. For the sake of correctness and simplicity, POST requests never trigger authentication requests or single signon.

After the filter makes the authentication request, the browser must determine how to proceed. If it can find appropriate credentials (a client-to-server ticket) then it will repeat the request (1) with the appropriate token in the header. Note that a browser may not respond to an authorization request if it cannot acquire credentials. The user will then not be able to view the site. Setting up the browser to avoid this is discussed in Browser Configuration. The filter is transparent to servlet responses. That is, responses from the servlet (4) pass through unchanged. Thus, responses from the application server are also unaffected by the filter. In other words, once Kerberos authentication completes and the user is issued a valid session ID, client/server messages will continue as if the filter was not present (the path going through 1, 5 and 4).

This table describes a typical single signon transaction in which Kerberos provides valid credentials during the authentication process:

Transaction Number

Description

1, 2

Unauthenticated client attempts to access a resource and KerberosSSOFilter requests authentication

1, 3, 4

Client responds with a Kerberos token, which KerberosSSOFilter validates and passes on to the servlet. The servlet passes it on to the application server, which signs the client on.

1, 5, 4, 1, 5, 4 ...

The rest of the communication passes through the KerberosSSOFilter unmodified

This table describes a typical single signon transaction in which Kerberos provides invalid credentials during the authentication process:

Transaction Number

Description

1, 2

Unauthenticated client attempts to access a resource and KerberosSSOFilter requests authentication

1, 6, 4

Client responds with a Kerberos token, which KerberosSSOFilter finds to be invalid. It removes the token from the request and forwards it on to the application server, which responds with a login page.

1, 7, 4

Client provides credentials using the login page (a POST operation). The servlet passes the credentials on to the application server which signs the client on.

1, 5, 4, 1, 5, 4 …

The rest of the communication passes through the KerberosSSOFilter unmodified

PeopleSoft Public Access and Signon PeopleCode for Kerberos Authentication

Although the web server performs Kerberos authentication, the application server is responsible for signon. The web server determines the network or directory username, but the application server must then map that name to a PeopleSoft user ID and sign the user in. To achieve single signon, the application server must perform these functions any time a user requests a PeopleSoft page, for example by clicking a link or by selecting a browser Favorite or Bookmark. You enable the application server to map the directory username to the PeopleSoft user ID by setting up public access, and then by adding a Kerberos authentication Signon PeopleCode function.

When a user who is not signed in requests a page, the application temporarily signs in as the public access user. You configure Single Signon settings that instruct the application server to run the KRB_AUTHENTICATION PeopleCode function in the FUNCLIB_LDAP record. This function checks for the request headers that the KerberosSSOFilter generates, and then performs the mapping and sign in operations.

The PeopleCode function that performs the user mapping depends on your specific implementation, but if you import your PeopleSoft users through LDAP from the same directory server that you use for Kerberos authentication, then the mapping is straightforward. For example, Kerberos authentication might return a username in this format: johnsmith@EXAMPLE.COM, while in your PeopleSoft application, the user ID is simply, johnsmith. In this case, the mapping operation merely strips @EXAMPLE.COM from the Kerberos username string.

Note: If the application server finds no authentication headers, then you should retrieve the PeopleSoft Sign In page so that a user is unaware of a failed attempt at authentication.

Browser Configuration

Internet Explorer default settings typically work with Kerberos single signon. However, if the browser settings are not the default, you might need to change the browser settings. In addition, Internet Explorer only uses Kerberos authentication for sites in the Local intranet zone. If your PeopleSoft applications are not within this zone, you must add them.

Considerations for Securing Kerberos Tokens Across the Enterprise

The previous sections discuss a web server-only implementation of Kerberos authentication. While this set up is a robust single signon solution, some elements remain less than optimally secure. In a web server-only implementation, the application server trusts any username that the web server places into the KRB_USER header. If the Kerberos token is accessed and manipulated between the web server and the application server, a hacker can very possibly sign in to PeopleSoft applications as any user. The web server-only configuration places an inordinate amount of trust on the PeopleSoft web server, yet ignores the connection between the web and application servers.

To make Kerberos authentication more secure, you can:

  • Configure the application server to re-validate the Kerberos token.

  • Configure the KerberosSSOFilter to request Kerberos tokens over a secure network connection only.

  • Bypass KerberosSSOFilter authentication and forward the Kerberos token directly to the application server.

By using these methods, you make it almost impossible to trick the application server with a username and prevent network traffic sniffing. You also decrease the load on the web server.

Understanding Kerberos Authentication on the Application Server

In a typical configuration, the web server forwards the Kerberos token that it receives from the client to the application server, but the application server ignores it. To make the token more secure, set up the application server to run a Java program that accesses and validates the Kerberos token. The program should check the keytab for the username (the same way that the KerberosSSOFilter does), compare the username from the keytab to the value in the KRB_USER header, and then only if they match continue the sign in process.

Understanding Kerberos Authentication on an Encrypted Network

Kerberos single signon should be done through an encrypted channel by using SSL/TLS. Encrypting the channel substantially increases security. Using a secure channel requires no changes to the Kerberos single signon configuration, only that PeopleSoft pages are accessed through HTTPS rather than HTTP. To help enforce this policy, configure the KerberosSSOFilter to request Kerberos tokens over a secure connection only. When you implement this configuration, the filter passes any request that comes over an non-secure connection directly to the web server.

Note: Requiring this setting is not always appropriate. If the web server uses a proxy to connect securely to the client, then the connection between the proxy and the web server might not be secure, although the connection to the client is. In this case, the KerberosSSOFilter will not recognize that the connection is actually secure and will not request authentication.

Forwarding Kerberos Tokens Directly to the Application Server

Another possible configuration is to have the KerberosSSOFilter perform no authentication, but to forward tokens directly to the application server. The filter still must request the token, but does not validate it or add a KRB_USER header before passing the message on. The application server is responsible for both validation and sign in. Although this configuration only requires one validation step, rather than two, it also prevents the KerberosSSOFilter from appending a mutual authentication token.

Typically, a mutual authentication token is returned as part of the response to a successful authentication attempt. In theory, the browser can use the token to verify the identity of the website—making the authentication mutual. In practice, however, neither Mozilla Firefox nor Microsoft Internet Explorer does this. Removing authentication from the filter simply decreases the load on the web server.

Configuring the Directory Server to Act as the Key Distribution Center KDC

To configure your directory server to act as the KDC:

  1. Create an appropriate server user account in the directory.

  2. Generate the keytab file. The keytab file stores the name and encrypted password of the server user account.

  3. Map the server user credentials to a Service Principal Name (SPN) matching the website that the server hosts.

    When a browser requests a client-to-server ticket for www.example.com, the browser asks the KDC for a ticket to a service principal named HTTP/www.example.com@example.com.

Setting up Kerberos Authentication on the Web Server

To set up Kerberos authentication on the web server:

  • Configure the web server JVM for Kerberos authentication.

  • Attach the KerberosSSOFilter to the PeopleSoft portal servlet.

Configure the Web Server JVM for Kerberos Authentication

To configure the web server JVM for Kerberos authentication:

  1. Place the keytab file in a folder, such as C:\krb\, on the server.

    The actual location is not important as long as it is accessible by the server.

    Important! Use caution when you transfer the keytab; any party that gains access to it can pose as the server.

  2. In the same folder, create two configuration files:

    • krb5.conf

      The krb5.conf file defines the domain to use for authentication and the domain controller to use as the KDC. For example, if you use the example.com domain with a domain controller at 192.168.1.1, then the krb5.conf file should contain:

      [libdefaults] default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = 192.168.1.1 }

    • krbLogin.conf.

      The krbLogin.conf file defines how the server authenticates against the KDC. For example, if you use a server that hosts www.example.com with keytab krb5.keytab in C:\krb\, then the krbLogin.conf file should contain: krbServer { com.sun.security.auth.module.Krb5LoginModule required storeKey=true useKeyTab=true keyTab="C:/krb/krb5.keytab" isInitiator=false principal="HTTP/www.example.com"; };

      Note: Use forward slashes in the keytab path.

  3. Configure the web server to use these files for Kerberos authentication, by adding JVM arguments.

    1. Edit the setEnv.cmd file in the <PS_HOME>\webserv\peoplesoft\bin\ directory.

    2. Find the line that begins with SET JAVA_OPTIONS_WIN= and append the line with this text:

      -Djava.security.auth.login.config="C:\krb\krbLogin.conf
      -Djava.security.krb5.conf="C:\krb\krb5.conf"
  4. Save the file.

Attaching the KerberosSSOFilter to the PeopleSoft Portal Servlet

To attach the KerberosSSOFilter to the PeopleSoft portal servlet:

  1. These Java class files should be present in the <PS_HOME>\webserv\peoplesoft\applications\peoplesoft\PORTAL.war\WEB INF\classes\com\peoplesoft\pt\desktopsso\kerberos directory.

    • KerberosSSOFilter.class

    • KerberosSSOFilter$1.class

    • KerberosSSOFilter$KerberosAuthWrapper.class

    • KerberosSSOFilter$KerberosHideWrapper.class

    Note: In addition to the compiled Java classes, all PeopleSoft applications include the Java source code for the Kerberos single signon. You can find the source code files in the <PS_HOME>\sdk\desktopsso\src\com\peoplesoft\pt\desktopsso\kerberos directory.

  2. Open the web.xml file in the <PS_HOME>\webserv\peoplesoft\applications\peoplesoft\PORTAL.war\WEB INF\ directory.

  3. Find the section that begins and ends with <display-name> ... </display-name> and below that section insert the following xml. This table describes the purpose of the xml.

    Description

    XML

    Begin the filter definition.

    Identify the filter as KerberosSSO.

    Identify the location of the KerberosSSO Java class files (Java servlet) that the web server calls.

    <filter>
        <filter-name>KerberosSSO</filter-name>
        <filter-class>com.peoplesoft.pt.
         desktopsso.kerberos.Kerberos
            SSOFilter</filter-class>

    Require a secure (HTTPS) connection for the authentication request.

    If the parameter value is true, use HTTPS connections only.

    If the parameter value is false, non-HTTPS connections are allowed.

    <init-param>
         <param-name>checkSecureConnection
         </param-name>
         <param-value>true</param-value>
    </init-param>
    

    Check for a valid Kerberos token.

    If parameter value is true, then the web server calls the KerberosSSOValidator Java class to validate the Kerberos token.

    If the parameter value is false, then bypass the web server and forward the Kerberos token to the application server for validation.

    Important! If set to false, you must set up the application server to call the KerberosSSOValidator Java class.

    See Understanding Single Signon.

    <init-param>
         <param-name>validateToken</param-name>
         <param-value>true</param-value>
    </init-param>
    

    Turn on verbose tracing of the Java class so that you can debug it if there is an issue.

    If the parameter value is true then the web server writes extensive comments to the Java console as the KerberosSSOValidator runs.

    If the parameter value is false then the web server does not create a debug file in the Java console as the KerberosSSOValidator runs.

    Note: The program doesn't create and store a physical log file on the web server.

    End the filter definition.

    <init-param>
          <param-name>verbose</param-name>
          <param-value>true</param-value>
    </init-param> 
    </filter>
    

    Map specific URLs to specific filters.

    Specify the Kerberos filter.

    Specify the URLs by their pattern; /* indicates that all URLs should be directed to the filter.

    <filter-mapping>
          <filter-name>KerberosSSO</filter-name>
          <url-pattern>/*</url-pattern>
    </filter-mapping>
  4. Save the file.

Setting up Kerberos Authentication on the Application Server

Setting up Kerberos authentication on the application server requires that you configure the application server JVM to validate the Kerberos token:

Configuring the Application Server JVM to Validate the Kerberos Token

To configure the application server JVM to validate the Kerberos token:

  1. These Java class files should be in the <PS_HOME>\class\com\peoplesoft\pt\desktopsso\kerberos directory.

    • KerberosSSOValidator.class

    • KerberosSSOValidator$1.class

    Note: In addition to the compiled Java classes, all PeopleSoft applications include the Java source code for the KerberosSSOValidator. You can find the source files in the <PS_HOME>\sdk\desktopsso\src\com\peoplesoft\pt\desktopsso\kerberos directory.

  2. Open the application server configuration file: psappsrv.cfg

  3. Find the line that begins with JavaVM Options=and append the line with this text:

    -Djava.security.auth.login.config=C:\krb\krbLogin.conf
    -Djava.security.krb5.conf=C:\krb\krb5.conf.
    
  4. Save the file.

Writing Signon PeopleCode for Kerberos Authentication

The Signon PeopleCode function that you create for Kerberos authentication can vary based on where you want authentication to occur. This section discusses Signon PeopleCode that implements Kerberos authentication:

  • At both the web and application servers.

  • At the application server only

Implementing Kerberos Authentication at Both the Web and Application Servers

To implement Kerberos authentication at both the web and application servers only:

  1. In PeopleSoft Application Designer, open the FUNCLIB_LDAP record definition. Right-click the LDAPAUTH field and select View PeopleCode.

  2. Find the Function getWWWAuthConfig() PeopleCode function.

  3. Change the &defaultUserId to “PUBUSER”.

  4. In the same field and event, add a KRB_AUTHENTICATION function.

    This table describes the elements that make up a sample Kerberos authentication Signon PeopleCode program:

    Code

    Description

    Function KRB_AUTHENTICATION()   
      
      If %PSAuthResult = True And
         &authMethod <> "WWW" And
         &authMethod <> "OAMSSO" And
         &authMethod <> "OSSO" And
         &authMethod <> "SSO" And
         &authMethod <> "LDAP" Then
    

    Declare the function.

    Check that the user is authorized and that the application is using no other authentication method.

            getWWWAuthConfig();
            If %SignonUserId = &defaultUserId Then
               Local string &princName = %Request.GetHeader("KRB_USER");
               Local string &krbToken = %Request.GetHeader("Authorization");
               Local string &userName = &princName;
               Local number &foundDelim = Find("@", &userName);
    

    Trust web server authentication.

    Verify that the public user is the current user and then,

    Retrieve the Authentication header from the KRB_USER and set it as the Kerberos token.

    Set the user name to be the principal name.

    Find the numeric location of the @ sign in the name.

               If (&foundDelim > 0) Then
                   &userName = Substring(&userName, 1, &foundDelim - 1);
               End-If;

    If there is something in front of the @ symbol in the name, then

    Strip the text that precedes the @ symbol and set it as the user name..

               If Len(&userName) > 0 Then
                   &krbToken = Substring(&krbToken, 11, Len(&krbToken) + 1);
                   &validator = GetJavaClass("com.peoplesoft.pt.desktopsso.kerberos.
    								KerberosSSOValidator").getInstance();
                   Local string &validUserName = &validator.validate(&krbToken);
    

    If there is a user name, then

    Extract the user name from the Kerberos token.

    Call the Kerberos validation program and validate the Kerberos token.

                   If &validUserName <> "NULL" And
                       &princName = &validUserName Then
                           SetAuthenticationResult(True, Upper(&userName), "", False);
                       &authMethod = "KRB";
                   End-If;
                End-If;
             End-If;
        End-If;
    End-Function;

    If the user name contains a value, then

    Compare the principal name to the name in the Kerberos token, and if the values are the same,

    Authenticate the user and sign in.

    Specify to the system that Kerberos authentication was performed so that other Signon PeopleCode functions can perform similar checks to the one at the beginning of function.

    Close the if statements.

    Close the function.

  5. Save the record definition.

Implementing Kerberos Authentication at the Application Server Only

To implement Kerberos authentication at the application server only:

Note: In the web.xml file on the web server, make sure that you have set the validateToken parameter to false so that the web server forwards the Kerberos token directly to the application server.

  1. In PeopleSoft Application Designer, open the FUNCLIB_LDAP record definition. Right-click the LDAPAUTH field and select View PeopleCode.

  2. Find the Function getWWWAuthConfig()PeopleCode function.

  3. Change the &defaultUserId to “PUBUSER”.

  4. In the same field and event, add a KRB_AUTHENTICATION function.

    This table describes the elements that make up a sample Kerberos authentication Signon PeopleCode program:

    Code

    Description

    Function KRB_AUTHENTICATION()   
      
      If %PSAuthResult = True And
         &authMethod <> "WWW" And
         &authMethod <> "OAMSSO" And
         &authMethod <> "OSSO" And
         &authMethod <> "SSO" And
         &authMethod <> "LDAP" Then
    

    Declare the function.

    Check that the user is authorized and that the application is using no other authentication method.

            getWWWAuthConfig();
            If %SignonUserId = &defaultUserId Then
               Local string &krbToken = %Request.GetHeader("Authorization");
               

    Trust web server authentication.

    Verify that the public user is the current user and then,

    Retrieve the Authentication header from the Kerberos token.

               If Len(&krbToken) > 12 Then
                   &krbToken = Substring(&krbToken, 11, Len(&krbToken) + 1);
    
                   &validator = GetJavaClass("com.peoplesoft.pt.desktopsso.kerberos.
    								KerberosSSOValidator").getInstance();
    
                   Local string &userName = &validator.validate(&krbToken);
    

    Extract the user name from the Kerberos token.

    Call the Kerberos validation program and validate the Kerberos token.

                   If &userName <> "NULL" Then
                       Local number &foundDelim = Find("@", &userName);
                       If (&foundDelim > 0) Then
                           &userName = Substring(&userName, 1, &foundDelim - 1);
                       End-If;
                           
                       SetAuthenticationResult(True, Upper(&userName), "", False);
                       &authMethod = "KRB";
                   End-If;
                End-If;
             End-If;
        End-If;
    End-Function;

    If the user name contains a value, then

    Find the @ symbol and strip the text that precedes the @ symbol and set it as the user name.

    Authenticate the user and sign in.

    Specify to the system that Kerberos authentication was performed so that other Signon PeopleCode functions can perform similar checks to the one at the beginning of function.

    Close the if statements.

    Close the function.

  5. Save the record definition.

Configuring a PeopleSoft Application to Use Kerberos Authentication

To configure the PeopleSoft application to use Kerberos authentication:

  • Enable public access.

  • Enable Kerberos authentication Signon PeopleCode.

Enabling Public Access

To enable public access:

  1. Select select PeopleTools, then select Web Profile, then select Web Profile Configuration and open the profile to which you are adding Kerberos authentication.

  2. On the Security tab, select the Allow Public Access check box and then enter the user ID and password of the public access PeopleSoft application user. This user should have minimal permissions.

    In this example, you see that public access is enabled as the user ID, PUBUSER.

    Image: Web Profile: Security page showing PUBUSER as the public access user

    This example shows the Web Profile: Security page with PUBUSER as the public access user.

    Web Profile: Security page showing PUBUSER as the public access user

    Note: You are not limited to PUBUSER as the user ID, however, the user ID on this page must be the same user ID that you entered in the getWWWAuthConfig()function in the Signon PeopleCode.

  3. Save the web profile.

Enabling Kerberos Authentication Signon PeopleCode

To enable Kerberos authentication Signon PeopleCode:

  1. Select select PeopleTools, then select Security, then select Security Objects, then select Signon PeopleCode.

  2. Insert a new row and enter these values:

    Field

    Value or State

    Enabled

    Selected

    Record

    FUNCLIB_LDAP

    Field Name

    LDAPAUTH

    Event Name

    FieldDefault

    Function Name

    KRB_AUTHENTICATION

    Exec Auth Fail

    Selected

    Sequence

    Enter a value that does not conflict with the flow of other Signon PeopleCode functions.

  3. Save the page.

    In this example, you see that the Kerberos authentication Signon PeopleCode, the KRB_AUTHE NTICATION function, is enabled:

    Image: Signon PeopleCode page showing Kerberos authentication Signon PeopleCode

    This example illustrates the Signon PeopleCode page showing Kerberos authentication Signon PeopleCode

    Signon PeopleCode page showing Kerberos authentication Signon PeopleCode