Support for External Login Pages

[JoelProminic]

From today's discussion, we need to support authentication though an external login page.

I would normally expect this to use /names.nsf?login, but I see that is not working for some servers. Doug suggested we use names.nsf instead. The server-specific login URL should be configured.

I intend to expose this configuration to Super.Human.Portal in a configuration agent that is called before XMLAuthenticationTest.

We should also pass a RedirectTo parameter to the login URL, to direct the user back to the portal once they are done authenticating. This didn't work like I remembered in my quick test, so I'll need to do more testing for this.

I think we should support using the built-in authentication prompt instead, if the user wants to use this.

[JoelProminic]

@piotrzarzycki21, I added the loginURL element to the XMLAuthenticationTest agent:

{
  "loginURL": "/names.nsf",
  "roles": [
    "Administrator"
  ],
  "errorMessage": "",
  "state": "authenticated",
  "common_name": "Anonymous",
  "username": "Anonymous",
  "status": "authenticated"
}

If the user is already authenticated (existing logic, if I remember correctly, this is status=authenticated), then ignore loginURL and open the application.

If loginURL is missing, null, or an empty string, then use the built-in Royale login interface.

Otherwise, open loginURL in a new tab. loginURL can be a full URL (i.e. https://domino.myserver.com/names.nsf) or an absolute path (/names.nsf). A releative URL would theoretically be possible, but I don't see a case where we would want this. The Royale interface is not responsible for validating the URL - this should be tested by the administrator.

I think the original plan was to open loginURL in the current window, but we'll need a way to redirect the user back to SuperHumanPortal. The options I see are:

• Require the Administrator to include the redirect in the URL. This would offer more control for custom solutions, but it puts more work on the administrator.
• Add logic to pass a redirect parameter along with the loginURL. This should work with the base names.nsf login, but it may not work for custom login URLs. I also worry we could run into CORS errors.

[piotrzarzycki21]

@piotrzarzycki21, I added the loginURL element to the XMLAuthenticationTest agent:

{
  "loginURL": "/names.nsf",
  "roles": [
    "Administrator"
  ],
  "errorMessage": "",
  "state": "authenticated",
  "common_name": "Anonymous",
  "username": "Anonymous",
  "status": "authenticated"
}

If the user is already authenticated (existing logic, if I remember correctly, this is status=authenticated), then ignore loginURL and open the application.

If loginURL is missing, null, or an empty string, then use the built-in Royale login interface.

Otherwise, open loginURL in a new tab. loginURL can be a full URL (i.e. https://domino.myserver.com/names.nsf) or an absolute path (/names.nsf). A releative URL would theoretically be possible, but I don't see a case where we would want this. The Royale interface is not responsible for validating the URL - this should be tested by the administrator.

I think the original plan was to open loginURL in the current window, but we'll need a way to redirect the user back to SuperHumanPortal. The options I see are:

• Require the Administrator to include the redirect in the URL. This would offer more control for custom solutions, but it puts more work on the administrator.
• Add logic to pass a redirect parameter along with the loginURL. This should work with the base names.nsf login, but it may not work for custom login URLs. I also worry we could run into CORS errors.

@JoelProminic I have deployed on my local server your agent. In configuration I have changed allow_anonymous to false. I called /SuperHumanPortal.nsf/XMLAuthenticationTest?OpenAgent and received following object:

There is no loginURL property - Am I doing something wrong ?

[JoelProminic]

We are looking into a solution to open the login page in the same window and redirect. We should have something for this already with MFA.

If we stick with the new tab solution, we'll need to display a message like this in the Super.Human.Portal window;

A login page has been opened in another tab. Please refresh this page once you have authenticated.

[piotrzarzycki21]

I have put below matrix of behaviour. Let me know if I miss something.

Auth status	loginURL	allow_anonymous	Behaviour
authenticated	ignored	true	Ignore loginURL - open app
authenticated	ignored	false	Ignore loginURL - open app
anonymous	ignored	true	Login as anonymous
anonymous	null	false	Show login page
anonymous	ignored	true	Login as anonymous
anonymous	not null	false	Show info - external logging

[piotrzarzycki21]

@JoelProminic I have pushed changes for this issue. It's ready for tests. I need suggestions what texts should I place in login screen ?

[piotrzarzycki21]

I have hide on login page "Forgot Password" and "New Registration" links - I feel like those are irrelevant here. If otherwise let me know. Just for the reference how it look like before hide.

[JoelProminic]

I see the current implementation is like this:

1. User opens page without authentication
2. Super.Human.Portal shows a message and a button to open the login page
3. User clicks the button and then logs in
4. User returns to the page and refreshes to access the application

The design I was envisioning here was:

1. User opens page without authentication
2. Super.Human.Portal opens the login page automatically in a new tab
3. The user logs in and closes tab
4. After returning to the Super.Human.Portal page, the user sees some instructions (see below)

The ideal solution would be more like this, but we don't have a good way to do this without relying on Domino server configuration (directory/file restrictions):

1. User opens page without authentication
2. The page redirects to the login page
3. The user logs in
4. The user is automatically redirected back

If we go with the second solution, we can display this message, which I suggested here:

A login page has been opened in another tab. Please refresh this page once you have authenticated.

If we go with the first solution, then we can display a message like this:

You are not authenticated. Click the button below to login, and refresh the page when done.

Button: "Open Login Page"

We could add a "Refresh" button for both cases.

The Forgot Password and New Registration buttons should be removed completely - I see they currently related to the MyAccount contact system, which we don't even want to use for Super.Human.Portal on Prominic servers.

Separately, we may need to think about the prominic.net image and other branding, if we expect other customers to use this as a portal for their staff. In the long term, we may need to provide an option for a customer icon instead.

[piotrzarzycki21]

Separately, we may need to think about the prominic.net image and other branding, if we expect other customers to use this as a portal for their staff. In the long term, we may need to provide an option for a customer icon instead.

I would add separate issue for that part.

[piotrzarzycki21]

If we go with the first solution, then we can display a message like this:

You are not authenticated. Click the button below to login, and refresh the page when done.

Button: "Open Login Page"

We could add a "Refresh" button for both cases.

I end up with that direction to do not confuse user. I have added "Refresh" button as well - I think it maybe good solution.

[JoelProminic]

We discussed the login page today, and we decided on this text and layout.

You are not authenticated. Click the Login button to continue. [Open Login Page in New Tab] [Refresh]

Super.Human.Portal should also periodically check XMLAuthenticationTest to see if the user has authenticated.

[piotrzarzycki21]

I have added testing authentication on login page every 5s. During work on that feature I have bump into scenario where question come out. Does user who has setup by admin allow_anonymous=true should have Logout button in UI ? I feel like it shouldn't - Login/Logout is for user who is non anonymous. What's your thoughts on that @JoelProminic ?

[JoelProminic]

For my later reference: @dpastov provided a solution to let this work with the MFA application. This requires a small update to MFA before it will work.

To use this solution, set login_url to /names.nsf?open&RedirectTo=/Super.Human.Portal/js-release/index.html (change to js-debug for development builds). Once the user logs in, they will be redirected to Super.Human.Portal. I tested that this works even if:

• The user fails their initial authentication attempt (changes the URL).
• The user chooses to open their MFA settings after the login. The user will be redirected after they click a button like "Login to my application"

However, this solution won't work with the default Notes authentication, and will not necessarily be supported by some other authentication solution.

[JoelProminic]

If the user is Anonymous then the Logout button does not make sense, so it should be hidden in this case. In this case, Logout is basically a page refresh, so it is not particularly disruptive.

Note that the user can still be authenticated if allow_anonymous=true if they authenticated for a different application. So, if a non-anonymous username is detected, the Logout button should still be displayed.

[piotrzarzycki21]

Note that the user can still be authenticated if allow_anonymous=true if they authenticated for a different application. So, if a non-anonymous username is detected, the Logout button should still be displayed.

I don't understand that part fully. I have allow_anonymous=true - what do I get when user is authenticated in the result of AuthTest here ? Right now I'm getting this, is this the scenario when Logout should be visible?

[JoelProminic]

@piotrzarzycki21, you can trigger this case like this:

1. Open https://%yourserver%/names.nsf . You should get an authentication prompt
2. Login as "Demo Admin". You can check the welcome page in SHI for the credentials.
3. After login, try to reload Super.Human.Portal. This should work, and you should see common_name=Demo Admin in the XMLAuthenticationTest response.
4. Super.Human.Portal should show the user name in the top right with a logout button in this case.

[piotrzarzycki21]

@piotrzarzycki21, you can trigger this case like this:

1. Open https://%yourserver%/names.nsf . You should get an authentication prompt
2. Login as "Demo Admin". You can check the welcome page in SHI for the credentials.
3. After login, try to reload Super.Human.Portal. This should work, and you should see common_name=Demo Admin in the XMLAuthenticationTest response.
4. Super.Human.Portal should show the user name in the top right with a logout button in this case.

So when I do Logout - what do I get in AuthTest ? My question is I have allow_anonymous=true - when do I login automatically and when do I show login page with our buttons ?

[JoelProminic]

Hmm, fair point. In this case, XMLAuthenticationTest would return Anonymous and Authenticated, and the application would be immediately opened. This could change the security permissions once I implement the agent logic. Otherwise, this would basically be a shortcut to logout on the server.

[piotrzarzycki21]

Otherwise, this would basically be a shortcut to logout on the server.

This part change behaviour of our application. We use Logout to jump to Login screen, but Login screen is displaying based on some specific scenario - if I logout anonymous - authenticated user - you need to return for me something which allows to stay on Login screen. Otherwise in my opinion no matter whether user is logging or not - in anonymouse state "Logout" button should be invisible.

[piotrzarzycki21]

Otherwise, this would basically be a shortcut to logout on the server.

This part change behaviour of our application. We use Logout to jump to Login screen, but Login screen is displaying based on some specific scenario - if I logout anonymous - authenticated user - you need to return for me something which allows to stay on Login screen. Otherwise in my opinion no matter whether user is logging or not - in anonymouse state "Logout" button should be invisible.

I have hide "Logout" button for anonymouse user. We can discuss after release state where it has to be visible in that state.

[JoelProminic]

I did some testing with the Logout button, and this mostly works:

User	AllowAnonymous	Logout
Anonymous	Yes	No
Demo Admin	Yes	Yes. BUG: Application automatically reloads as Anonymous, but it still shows the authenticated user name and the Logout button
Anonymous	No	N/A
Demo Admin	No	Yes, works as expected

[piotrzarzycki21]

Demo Admin Yes Yes. BUG: Application automatically reloads as Anonymous, but it still shows the authenticated user name and the Logout button

@JoelProminic I have fixed that bug as follows: When user logged in as allow_anonymous=false username=Demo Admin and next during ongoing session change allow_anonymous=true - click "Logout" - application refresh UI and "Logout" button disappear. After release we can discuss what we should do in the state when user have allow_anonymous=true and he is still logged in.

[JoelProminic]

I confirmed the username is cleared on logout with the latest update.