# Implementing Authentication

WebLogic Portal provides many different ways to implement user login and authentication against any available authentication providers. The following sections provide nine authentication samples to help you better understand the choices you have in implementing authentication. These sections are taken directly from the samples in the Tutorial Portal.

Note: This topic describes how to implement authentication after authentication providers have been configured for use with WebLogic Server. For information on setting up authentication providers, see Using Multiple Authentication Providers In Portal Development.

In these samples, the portal Web project root is <WEBLOGIC_HOME>/samples/portal/portalApp/tutorial. Paths in the samples are relative to this root. All resources and configuration for these samples is included in the tutorial portal Web project which uses the <WEBLOGIC_HOME>/samples/domains/portal/config.xml server (called portalServer). To use these samples in your own domains and portal Web projects, import or mimic the files and configurations used in the samples.

This topic includes the following samples:

1. Form Based
2. Client Certificate
3. Backing File
4. Multi-Page User Registration Using Page Flow
5. Single Sign-on Within WebLogic with a Second Application
6. Auto Login
7. Basic Authentication
8. Portal Access that Requires Login
9. Perimeter Login
10. User Login Control

## 1. Form Based

Source Location: /portlets/login/formLogin/

The example /WEB-INF/web.xml specifies a CONFIDENTIAL transport-guarantee so the /portlets/login/formLogin/login_link.jsp must build a HTTPS URL to access the redirect.jsp. The redirect.jsp simply redirects back to the portal. This example leaves the protocol in HTTPS, but you could switch back to HTTP in redirect.jsp if you only wanted HTTPS to protect your username/password during login.

Note: The <form-login-page> URLs specified in web.xml will be different based on whether you are running the portal from a .portal file in WebLogic Workshop or assembled from the database when you create a desktop in the WebLogic Administration Portal. For example, when running a file based portal such as sample.portal (in development) the <form-login-page> element might be specified with
/samplel.portal?_nfpb=true&_pageLabel=login. When running an assembled portal (in production) the <form-login-page> element might be specified with /appmanager/samplePortal/sampleDesktop?_nfpb=true&_pageLabel=login.

## 2. Client Certificate

Source Location: /portlets/login/clientCert/

These are the steps for using client certificate authorization:

1. Comment out the FORM or BASIC <login-config> in /WEB-INF/web.xml and uncomment the CLIENT-CERT <login-config>. This is necessary because the Web application can have only a single login-config.
2. Next you can do one of 2 things:
   - Import the democlient-cert.p12 client certificate into your browser, located in /portlets/login/clientCert/.
     or
   - Generate your own certificate using openssl.

   Note: democlient-cert.p12 was created for demonstration purposes and is not meant for production use. If you choose to generate your own certificate using openssl, they have instructions at their Web site at www.openssl.org.

3. If you import democlient-cert.p12, the following is for importing into IE version 6:
   1. Double-click the democlient-cert.p12 file.
   2. Click Next when the Certificate Import Wizard appears.
   3. democlient-cert.p12 should be displayed in the filename textbox. Click Next.
   4. Do not type a password for the private key. Click Next.
   5. You can select a certificate store or not. Click Next.
   6. Click Finish.

The following steps are for configuring WebLogic Server to use SSL and the democlient-cert correctly.

4. With a running portalServer, open the WebLogic Administration Console (http://<server>:<port>/console).
5. Using the tree view pane, navigate to Security > Realms > realmName > Providers > Authentication > DefaultIdentityAsserter.
6. In the User Name Mapper Class Name textbox, enter examples.login.ExampleUserNameMapper.
7. Move the X.509 certificate type to the Chosen box and click Apply.
8. Navigate to Security > Realms > realmName > Users and create a new user called support with password of password.
9. Navigate to Servers > portalServer and click the Keystores and SSL tab.
10. Click the Show link for the Advanced Options at the bottom of the page.
11. Select Client Certs Requested But Not Enforced from the Two Way Client Cert Behavior drop down (or enforced depending on the desired behavior) and click Apply.
12. Add the examples.login.ExampleUserNameMapper.class to the system classpath. This can be accomplished by adding the class to netuix_system.jar. The ExampleUserNameMapper extracts the username from the e-mail of the Subject DN in the X.509 certificate. For example, the democlient-cert.p12 has a Subject DN with an e-mail of support@bea.com and the resulting username is "support". This is why the support user was added to the realm in the previous steps.

Because the form-based login example uses SSL, the one-way SSL was already configured for the server. If you need to enable client-certificate authentication for any server, it is a prerequisite to configure one-way SSL (see "Configuring SSL" in "Managing WebLogic Security" at http://e-docs.bea.com/wls/docs81/secmanage/ssl.html).

After you take these steps, you can access the portal and /portlets/login/formLogin/login_link.jsp to use your client certificate to get logged in to the portal Web application. See the form-based login example for an explanation of the use of the login link to access a protected resource.

## 3. Backing file

Source Location: /portlets/login/backingFileLogin/

This example uses portal personalization code and a backing file to log in (/WEB-INF/src/portlet/login/LoginBacking.java). The backing file also redirects back to the portal so that database state is not clobbered by control state.

## 4. Multi-Page User Registration Using Page Flow

Source Location: /portlets/login/pageflowLogin/

This example uses Java Page Flow to show how a multi-page user registration portlet can be accomplished. This example has 4 pages:

1. The first displays a simple user registration page.
2. The second page gathers more user information that could be stored in user properties (personalization code).
3. The third page will optionally authenticate the user or show a summary page (2 links).
4. The fourth page is either the logged in status of the user or the summary page.

## 5. Single Sign-on Within WebLogic with a Second Application

Source Location: /portlets/login/ssoLogin/

This is an example of single sign-on between two Web applications. For single sign-on to work, both Web applications must have matching cookie name entries in web.xml. Since by default WebLogic sets the cookie names to be identical if unspecified for a Web application, this behavior should work by default.

## 6. Auto Login

Source Location: /portlets/login/autologin/

Note: This example uses cookies, which is an insecure authentication method.

This example shows how to use cookies and encoding for autologin. When you login and select the "autologin" checkbox, it will encode your username and password. The username and password will be added as a cookie to the response for a life of 1 day. After this point, if you leave the portal and come back, you will be logged in automatically, including when you exit the browser. If you log out, the cookies will be deleted and you will no longer be automatically logged in when you revisit the portal.

This example uses a backing file (/WEB-INF/src/portlet/login/AutoLoginBacking.java).

## 7. Basic Authentication

Source Location: /portlets/login/basicLogin/

This example uses the same principles as the form-based login. To use basic authentication, simply uncomment the FORM or CLIENT-CERT based authentication methods in web.xml, and use the basic method of authentication. You can use one of the default users in the realm such as visitor1/password to log in.

## 8. Portal Access that Requires Login

Source Location: /portlets/login/loginRequiredPortal/

This example shows a portal that is only accessible after user authentication. To enable this, simply add a security constraint entry in web.xml for all URL resources. For Example:

    <security-constraint>
        <web-resource-collection>
            <web-resource-name>login</web-resource-name>
            <description>Security constraint for the whole portal</description>
            <url-pattern>/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <description>all users</description>
            <role-name>AnonymousRole</role-name>
        </auth-constraint>
    </security-constraint>

## 9. Perimeter Login

Source Location: /portlets/login/perimeterLogin/

See the following WebLogic Server documentation topics:

- "The Authentication Process" in "WebLogic Security Service Architecture" at http://e-docs.bea.com/wls/docs81/secintro/archtect.html.
- "Configuring Security Providers" at http://edocs/wls/docs81/secmanage/providers.html, especially the following sections:
  - Configuring a WebLogic Authentication Provider
  - Configuring a WebLogic Identity Assertion Provider

Related Topics

Tutorial Sample

How WebLogic Portal Uses the WebLogic Server Security Framework