TIP: Overview of the Single-Sign-On login flow in an OutSystems application

TIP: Overview of the Single-Sign-On login flow in an OutSystems application

  
Hi,

Following-up on a previous conversation about the OutSystems Single-Sign-On (SSO) login process in this forums, I decided to share in a separate thread an overview of the execution flow of the SSO login process in a typical OutSystems application - an application based on the OutSystems Style Guide.

Goal of the OutSystems Single-Sign-On process 

The goal of the OutSystems SSO login flow is to guarantee that, when a user first accesses and OutSystems application, he is automatically redirected to the login screen so that he can input his credentials and be granted all the permissions that are configured for him in the User Configuration of the OutSystems Enterprise Manager Backoffice.
Please bare in mind that the SSO functionality is immediately available in any OutSystems application based on the Style Guide - you do not need to understand it to develop application with SSOLogin or Security. My goal is to give an high level overview to those who need to extend it, need to debug it for specific application reasons or are simply curious.

I am assuming that in versions prior to OutSystems 5.1, the applications are based on the  OutSystems Style Guide template eSpace; for OutSystems versions 5.1 and onwards I am assuming the  application is created in Service Studio with the New > From Style Guide functionality (see below).



OutSystems Single Sign On execution flow

The execution flow of a first user access to an OutSystems Application in a session, that takes him through the Single-Sign-On Login screen is the following:
  1. The User accesses a Web Screen. He is seen by the OutSystems platform as an Anonymous User because he did not login yet ;
  2. If this Web Screen has security access in place (only users with specific permission areas can access the screen), a Security Exception is thrown - this happens because the user is anonymous, meaning that he has no permission areas set in his session context;
  3. The Web Flow Security Exception Error Handler already available in the Style Guide catches the thrown exception;
  4. In this Web Flow, the Security Exception Handler can go two ways:
    • If the user is already logged-in (that is not the case in our example), a No Permissions screen is shown;
    • If the user is not logged-in (that is the case in our example), the user is redirected to the Login screen;
    • Note: In versions of the OutSystems platform previous to 5.1 you needed to have security error handling on every web flow for the login flow to work. From version 5.1 onwards, the redirection to the login flow in the Exceptions Web Flow is done automatically without the need for security error handling being placed explicitly on every webflow.
  5. The user will be redirected to the Login Page where he can insert his username and password.
  6. By inserting the Username and Password in the Login Screen, the user will be granted all the Privileges configured for him in the Enterprise Manager Backoffice; These Privileges will be available throughout his session.
  7. After granting all the correct permissions for the user, the Enterprise Manager will now redirect the User to the initial Web Screen.
    • If the user does not have the necessary permissions to access the Web Screen, a new Security Exception will be triggered and the flow will repeat itself, the difference is that this time on the step 4 the user will be redirected to the No Permissions screen (because he is already logged in);
    • If the user has the necessary permissions to see the Web Screen (granted on login), he will see the Web Screen in his browser.
 Kind Regards,

Daniel Lourenço
OutSystems