Extending Login and Splash Page Behavior
To understand the login process and flow of events, it helps to analyze an example of how a system administrator would extend a deployment to have custom login page behavior. The following set of steps uses the concepts of anonymous access, forms-based authentication, and login pages to form a solution. Some of the steps require developer knowledge.
1. Design a page that has a login portlet on it. Once the page is created, set the authentication scheme of the page to “anonymous” so everyone can get to the page and be presented with the login portlet.
Optionally, you can set access rights on other parts of the page so that the login page has different appearances, depending on the identities of users. To address even broader requirements of personalizing the login page, it is also easy to set up custom login pages based on rules themselves.
2. After setting the authentication scheme of the page to anonymous, make sure the login portlet itself can be seen by a Guest user. For more information about the Guest user, see
Managing Directory Services. You may also want to modify the look and feel of the page by removing title bars, adding explicit instructions, or implementing other business requirements.
3. You can control where a user is redirected after login. In the Properties page for the login portlet, modify the Login Target property to the page where the user is redirected. Keep in mind that the Login Target be static or it can be an alias. If you use an alias like /user.current.start.page, you can alternatively set up start page rules to govern different start pages based on information about the user logging in.
It is also possible to redirect a request, if not authenticated, to go to the appropriate login page. To do so, modify the Redirect URI property of the authentication scheme assigned to the page. When an unauthenticated user requests the page, the user is redirected to the specified page. As with login targets, a redirect URI can be either static or an alias.