You might have hit a very common wall trying to access your Mentor Generated apps with a Member access user (IT-users / Dev). 

This guide explains the two built-in authentication methods in your ODC Personal Edition, which role each plays in the normal usage of our PE and how to configure your apps to allow everyone to login. 

ODC Personal Edition and Identity Providers

Personal Edition has 2 pre-built Identity Providers: 

• Built-in Provider: where all end-users are registered by default, can log in via username and password (local credentials). These are the users you invite to your tenant to access your applications.
• Built-in community provider: when using this Identity Provider, users will authenticate against the OutSystems Community Identity Provider, which means they should use their Community account to access the applications. The user who launched the Personal Edition is configured to use this IdP as well as any other Organization Member users added to the Tenant. 

The way a user logs in depends on their role and the Identity Provider (IdP) being used.

Note: For applications generated via Mentor, the sample users are created in the Built-in Provider.

Understanding End-User Access for Organization

For users with Organization Member access within the ODC tenant, the process for accessing OutSystems applications is distinct from that of a standard end-user. For an Organization Member User, you need to log in to the app using single sign-on with your Outsystems Community account, rather than using your email address and password, as a regular end-user

In contrast, a regular end-user (one who does not have the Organization Member access type) authenticates using a more conventional method: their specific email address and a password that is typically managed within the application's user database or an integrated user store.

In summary:

• Organization Member User: Must log in using Single Sign-On (SSO) with their OutSystems Community account.
• Regular End-User (Non-Member): Logs in using their email address and password.

IMPORTANT!! Attempting to log in as an Organization Member using the standard email and password method (as a Regular End-User would) will result in failure. The platform is specifically looking for the SSO flow tied to your Community Identity -  and overcoming this is what we propose to address in this Post. 

Now, what's the plan to sort this out?

This post presents a solution to overcome this roadblock by setting up an alternative login flow using the Built-in Community Identity provider.

Step 1: Add the Authentication system actions Public Elements to your App:

• GetExternalIdentityProviders: Gets the list of external Identity Providers configured for the stage. Returns an empty list if no providers are configured.
• GetExternalLoginURL: If an identity provider is configured for the app returns the ExternalLoginURL to redirect the user to the identity provider's login page.
• GetExternalLogoutURL: If an identity provider is configured for the app and the user is logged in returns the ExternalLogoutURL to redirect the user to the identity provider's logout page.

* Link for Documentation here.

Step 2: Adding the IdP Flow to Login screen

On the OnInitialize Client Action, fetch the configured Identity Providers in ODC Portal so that we have them listed in the login screen. For that, it will be used the GetExternalIdentityProviders: 

Create a new local variable called ExternalIdentityProviders of ExternalIdentityProvider List type and assign it to the output of the GetExternalIdentityProviders client action:

Step 3: match those changes in the Login Screen UI

1. Add a new container inside the LoginContainer and add a text element stating “or Use an External IdP”
   
2. Add a new container and name it IdPLoginContainer.

3. Add a List Element inside the created container, assign the ExternalIdentityProviders variable as source and add a button ButtonLoading as the image below shows (for the ButtonLoading isLoading property add the expression ExecutingLoginExtIdPKey = ExternalIdentityProviders.Current.Key, where ExecutingLoginExtIdPKey is a variable of type text):
   

4. Create a new Client Action for the Button On Click Event and name it LoginIdPOnClick

5. Add an Assign element:

   ExecutingLoginExtIdPKey = ProviderKey

   Place the GetExternalLoginURL and end the Flow with a Destination Node mapped for the RedirectToURL External Site. 

6. Create an Exception Handler Flow, for all exceptions that may be raised during the execution of the action, add an assign element with the following mapping:

   ExecutingLoginExtIdPKey = “”

   Add a Message node with the error type and assign the Exception Handler output parameter as the message attribute: 

   Message = AllExceptions.ExceptionMessage
   
   The final flow of the LoginIdPOnClick Client Action should look like this: 
   
   
   
   

Step 4: Logout Flow

1. Go to the UserInfo block and double-click on the ClientLogout Client Action.
2. Create a new local variable and name it RedirectURL.
3. Add an If element right after the starting node with the condition set to IsExternalUser() - this function validates if the logged-in user is from an external identity provider. Intended for use cases where we need to filter operations only available for users from the built-in identity provider.
4. Add the GetExternalLogoutURL client action after the if statement, in the True branch. Then, place an Assign Node right after it, name it Set external RedirectURL and then perform the following mapping: 
   RedirectURL = GetExternalLogoutURL.ExternalLogoutURL
   
   Where RedirectURL is a new Local Variable of text type
   
   
5. On the False branch, place an Assign Node right after the Logout, name it Set internal RedirectURLand then perform the following mapping: 

   RedirectURL = GetOwnerURLPath()
   
   

6. The Client Logout Action should look like this:

   

    

This customized flow will allow our application to behave differently depending on the login method used by the end user. 

Note: This practice works the same and is also valid for apps downloaded from Forge that do not have a defined Login flow for External Identity Providers.

Conclusion and Key Takeaways

Organization Member Users (IT Users/developers) in an ODC Personal Edition encounter a "login wall" when attempting to access applications created by a Mentor or installed from the Forge. This occurs because the system uses the default Identity Provider (IdP) for authentication instead of the Community Identity Provider, which is where these users are defined.

By implementing the steps presented above, your application will have implementation of an alternative login flow through the Community IdP, as shown in the screenshots listed below.