Try OpenEdge Now
skip to main content
Customization Guide
Customizing Login pages using BPM Sign-on API : Reviewing logging in actions
 

Reviewing logging in actions

In the example shown in Figure 4, there are three separate machines/Web applications. The Machine2/WebApp2 is the Business Process Server machine. As an example, the following actions occur when BPM Sign-on is used to enable users to log in to multiple Web sites that share a common Login page.
*The first time the user tries to access any of the three Web applications, for example, WebApp2 (Business Process Server), BizPassFilter2 verifies that there is no valid session between the browser and WebApp2. As a result, the user is redirected to the common Login page residing under the BPM Sign-on domain on machine0. The link to the requested page is also communicated to BPM Sign-on as part of a redirection parameter, and is stored there for future references.
*After successful authentication, a valid BPM Sign-on session (session0) is maintained between the browser and the BPM Sign-on Web application. Then the user is redirected to the originally requested page. User ID and password are posted as part of the HTTP request.
*BizPassFilter2 in the Business Process Server domain gets the user ID and password to create the Business Process Server portal-specific beans (BizSiteBean, BPMManageBean, and so on) and put them into the newly created session, session2.
*The next time the user accesses Business Process Server functionality, it is possible to directly jump to the requested page, without entering User ID and password again, as long as a valid session (session2) is maintained between the browser and WebApp2. Also note that the necessary Business Process Server beans have already been created.
*Now if the user wants to access WebApp1, BizPassFilter1 does not recognize a valid session between the browser and WebApp1 at first, and redirects the user to the BPM Sign-on domain along with the WebApp1 information. Since session0 still exists, the login process is skipped and the browser is redirected back to WebApp1, which can now access the user ID and password passed through the HTTP request.
*In case the user clicks again on any link under WebApp1 after navigating to some other Web site, the corresponding page will be automatically brought up into the browser, because the bean initialization (in session1) steps have already taken place in the past.
*The BizPassFilter1 must initialize the session1 with WebApp1, which may require the user ID and password to create the necessary resources such as portal-specific beans.
*This model of single sign-on can be generalized to any number of Web applications.