Separate Authentication Roles

[JoelProminic]

We spent some time today discussing how we want Super.Human.Portal to work as a customer portal. We quickly released that there were some features here that should not be exposed to end-users. For example:

• add/edit/delete bookmarks - the bookmarks should be fixed by the administrator, unless/until we allow user-specific bookmarks
• Install applications
• Viewing the installed applications, including the bookmarks?

Doug suggested authentication roles like this. I'd like to think about these further:

• view bookmarks
• view installed applications
• update bookmarks and install applications

These roles will be enforced by the agents, but they should also change the UI. I am planning to update XMLAuthenticationTest (or a similar post-authentication agent) to include flags for the different allowed roles.

[JoelProminic]

Here are the main features I am seeing with Super.Human.Portal that may need separate roles. I am including my initial role suggestions. I'll plan to discuss this with @JustinProminic in the meeting tomorrow:

Feature	Roles
Login	Authenticate
View Documentastion (Getting Started)	Documentation
Install Applications	ApplicationManager
Add additional Genesis Directories	ApplicationManager
View installed applications	ApplicationManager
View/Use Bookmakrs	Bookmarks
Create/Edit/Delete Bookmarks	BookmarkAdmin
Browse My Server	BrowserServer

Here are my proposed application roles:

Role	Description
Authenticate	Application access. Should this be implied by having at least one of the other roles? This could allow quick global lockouts, but it could also increase the number of gropus that need to be updated.
Documentation	Access to documentation (Getting Started). This documentation seems more focused for administrators/developers rather than end users.
ApplicationManager	View and install Genesis Applications, and add additional directories
Bookmarks	View and use bookmarks
BookmarkManager	Create/Edit/Delete bookmarks
BrowseServer	Use Browse My Server. Does it make more sense to merge this with BookmarkManager?

We'll also want to think about how this should work with test servers created from SHI. In this case, it would be useful to allow anonymous access to all features so that the user doesn't need to mess with authentication, but they would need to remember to add the security options if they want to make the website public later.

When installed from Genesis, the roles should be set to safe defaults. Should we limit it everything to the LocalDomainAdmins group?

[JoelProminic]

I'm also thinking about how to define the roles:

• ACL - For consistency with the Domino security strategy. This is problematic because if the ACL access is two low, it can prevent the agents from being called at all.
• names.nsf groups - This would also fit well with Domino. I have concerns about how I will efficiently process the groups with unlimited nesting, though. I could pre-compute the access and cache it in documents, but verifying that the cache is up-to-date would be expensive.
• Config value with groups (and individuial users?) - Same as "names.nsf groups", but more isolated to application.
• Config value with users only - Avoids lookup issues, but could be difficult to maintain for large numbers of users.
• New Role field on Person documents - Would require names.nsf changes, so probably not practical. Similar to how Contacts security works. Efficient lookup, but could be harder to maintain for many users.
• UserRole documents in SuperHumanPortal.nsf - Similar to "New Role field on Person documents", but avoids names.nsf chagnes. More duplication for users.

The original plan we discussed was "Config value with groups (and individual users?)", and I'm still favoring this. My main concern is the performance.

[JoelProminic]

After discussing this in the meeting today, we decided to simplify the design for the initial release:

• The main sensitive features will be restricted to a single "Administrator" role:
  • Install Applications
  • Add additional Genesis Directories
  • View installed applications
  • Create/Edit/Delete Bookmarks
• The "Administrator" role will initially be determined by a configuration document, which will be limited to a list of users (instead of groups). This can be changed on the backend
• User authentication will only be restricted by allow_anonymous. So either only authenticated users, or all users including anonymous.

I'm planning to write the agent in a way that we can replace the backend logic later.

[JoelProminic]

I made some placeholder updates to the XMLAuthenticationTest agent so that @piotrzarzycki21 can start on updates.

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

The Royale interface should then retrieve the list of roles from the XMLAuthenticationTest output.

These interfaces should only be displayed if the user has the "Administrator" role.

• Genesis Apps
• Genesis Apps / Additional Directories
• Installed Applications

And then these buttons should only be enabled if the "Administrator" role is present:

• Bookmarks: Add/Edit/Delete
• Bookmarks/Browse My Server: Add Bookmarks

By default, the agent won't return any roles. To change this, open the Configuration view in SuperHumanPortal.nsf on your test server, and create a new document called "test_security_roles". Set the value to "Administrator" to test the "Administrator" role (if you want to test additional values, separate them with ";").

[piotrzarzycki21]

And then these buttons should only be enabled if the "Administrator" role is present:

• Bookmarks: Add/Edit/Delete
• Bookmarks/Browse My Server: Add Bookmarks

Roles has been implemented for this part. I'm working on adding them to the rest which is a little more tricky.

[piotrzarzycki21]

These interfaces should only be displayed if the user has the "Administrator" role.

• Genesis Apps
• Genesis Apps / Additional Directories
• Installed Applications

Roles to handle that was implemented as well.

[JoelProminic]

I did some tests. The problematic cases are bolded

Feature	Administrator	No roles	"Adminstrators"	Administrator + other roles
Genesis Apps	Visible	Hidden	Hidden	Visible
Genesis Apps / Additional Directories	Visible	Hidden	Hidden	Visible
Installed Applications	Visible	Hidden	Hidden	Visible
Bookmarks:	-	-	-	-
Add	Visible	Visible	Visible	Visible
Edit	Disabled	Disabled	Disabled	Disabled
Delete	Disabled	Disabled	Disabled	Disabled
Bookmarks/Browse My Server: Add Bookmarks	Visible	Disabled	Disabled	Visible

I think it would be better to fully hide the bookmark buttons rather than disabling them when the user does not have the Administrator role, so that the user doesn't even see that it is an option. We can discuss this in the meeting tomorrow, if needed.

[piotrzarzycki21]

ApplicationManager

I think we should test during the meeting this part. I have pushed changes to make some buttons hidden, fixed where "Add Bookmarks" button was visible in "Bookmarks", but apart of that I don't understand where is issue in case of "No roles" and non editable buttons "Edit" in bookmarks. I thought this is the goal of having it non editable/hidden in that scenario.

[piotrzarzycki21]

@JoelProminic please test that part. After release we can pursue to our original idea to have more roles options.

[JoelProminic]

I remember doing some tests for the updates, probably during the Wednesday meeting. It seems I didn't document them, though, so I'll plan to add something for this.

As you say, this issue is only for the Administrator role. More roles can be added later.

This issue needs to remain open until I get the full agent implementation done.

[JoelProminic]

I revisited the test. I retested the section hiding because it was fast:

Feature	Administrator	No roles	"Adminstrators"	Administrator + other roles
Genesis Apps	Visible	Hidden	Hidden	Visible
Genesis Apps / Additional Directories	Visible	Hidden	Hidden	Visible
Installed Applications	Visible	Hidden	Hidden	Visible
Bookmarks:	-	-	-	-
Add	Visible	Hidden	Hidden	Visible
Edit	Visible	Hidden	Hidden	Visible
Delete	Visible	Hidden	Hidden	Visible
Bookmarks/Browse My Server: Add Bookmarks	Visible	Hidden	Hidden	Visible

This looks good. The agent updates are still pending. I'm planning on spending time with this today.

[JoelProminic]

I have an initial implementation of the role security written. For now, I have the documentation in the javadoc comment.

I added it to XMLAuthentication to start doing some testing for the logic. (For now, I am supporting "test_security_roles" to override these values, but I should continue removing this before the release).

User	allow_anonymous	role_Administrator_users	Expected Roles	Actual Roles	Notes
Anonymous	false	Demo Admin	None		No roles are allowed for Anonymous in this case
Anonymous	false	Anonymous; Demo Admin		No roles are allowed for Anonymous in this case
Anonymous	true	Demo Admin	All, Anonymous		Default roles
Anonymous	true	Anonymous; Demo Admin	All, Anonymous, Administrator		Support for "Anonymous" user entry
Anonymous	true	*	All, Anonymous, Administrator		Anonymous is included in wildcard
Anonymous	true	*/*	All, Anonymous		Anonymous is not included in user wildcard
Demo Admin	true	Demo Admin	All, NotAnonymous, Administrator		Simple match
Demo Admin	false	Demo Admin	All, NotAnonymous, Administrator		allow_anonymous doesn't matter
Demo Admin	-	``	All, NotAnonymous		Default Roles
Demo Admin	-	Demo Admin/DEMOPROD	All, NotAnonymous, Administrator		Abbreviated
Demo Admin	-	CN=Demo Admin/CN=DEMOPROD	All, NotAnonymous, Administrator		Canonical
Demo Admin	-	*	All, NotAnonymous, Administrator		Wildcard
Demo Admin	-	*/*	All, NotAnonymous, Administrator		User Wildcard
Demo Admin	-	*/DEMOPROD	All, NotAnonymous, Administrator		Organization Wildcard
Demo Admin	-	demo admin	All, NotAnonymous, Administrator		Case insensitive
Demo Admin	-	demo admin/demoprod	All, NotAnonymous, Administrator
Demo Admin	-	cn=demo admin/cn=demoprod	All, NotAnonymous, Administrator

I ran out of time for the testing today, so I haven't committed any agent updates yet. Looking at the table above, I think I could probably make some automated tests with Spock, though I'd want to override the Domino lookups with test data.

NOTE: @piotrzarzycki21, you don't need to worry about any of the roles besides "Administrator" for now. These roles will be used by the agents so that I can define role(s) for each agent in the next step.

[JoelProminic]

XMLAuthenticationTest is updated and working. I had to fix some bugs in SimpleRoleSecurity.

User	allow_anonymous	role_Administrator_users	Expected Roles	Actual Roles	Notes
Anonymous	false	Demo Admin	None	Confirmed	No roles are allowed for Anonymous in this case
Anonymous	false	Anonymous; Demo Admin	Confirmed	No roles are allowed for Anonymous in this case
Anonymous	true	Demo Admin	All, Anonymous	Confirmed	Default roles
Anonymous	true	Anonymous; Demo Admin	All, Anonymous, Administrator	Confirmed	Support for "Anonymous" user entry
Anonymous	true	*	All, Anonymous, Administrator	Confirmed	Anonymous is included in wildcard
Anonymous	true	*/*	All, Anonymous	Confirmed	Anonymous is not included in user wildcard
Demo Admin	true	Demo Admin	All, NotAnonymous, Administrator	Confirmed	Simple match
Demo Admin	false	Demo Admin	All, NotAnonymous, Administrator	Confirmed	allow_anonymous doesn't matter
Demo Admin	-	``	All, NotAnonymous	Confirmed	Default Roles
Demo Admin	-	Demo Admin/DEMOPROD	All, NotAnonymous, Administrator	Confirmed	Abbreviated
Demo Admin	-	CN=Demo Admin/O=DEMOPROD	All, NotAnonymous, Administrator	Confirmed	Canonical
Demo Admin	-	*	All, NotAnonymous, Administrator	Confirmed	Wildcard
Demo Admin	-	*/*	All, NotAnonymous, Administrator	Confirmed	User Wildcard
Demo Admin	-	*/DEMOPROD	All, NotAnonymous, Administrator	Confirmed	Organization Wildcard
Demo Admin	-	demo admin	All, NotAnonymous, Administrator	Confirmed	Case insensitive
Demo Admin	-	demo admin/demoprod	All, NotAnonymous, Administrator	Confirmed
Demo Admin	-	cn=demo admin/o=demoprod	All, NotAnonymous, Administrator	Confirmed
Demo Admin	-	*/demoprod	All, NotAnonymous, Administrator	Confirmed

I ran the above tests manually. It went pretty fast (when I wasn't debugging problems) but I would like to implement the automated tests while the idea is fresh in my mind.

[piotrzarzycki21]

@JoelProminic should I setup role_Administrator_users to test above cases in portal ? "Expeted Roles" will be value?

[JoelProminic]

@piotrzarzycki21, if you want to use the new configuration you should set these config values:

Key	Value
role_list	Administrator
role_Administrator_users	Demo Admin
test_security_roles	*Delete or rename to xtest_security_roles

I'm working on the individual agent updates today. Hopefully this shouldn't take very long.

[JoelProminic]

I updated the agents, and started running some tests through Super.Human.Portal. The remaining tests will be need to be tested directly, which will take longer.

Agent	User	Expected	Test
XMLAuthenticationTest	Anonymous (allow=false)	Not Allowed	Confirmed
XMLAuthenticationTest	Anonymous	Allowed	Confirmed
XMLAuthenticationTest	Demo Admin	Allowed	Confirmed
XMLAuthenticationTest	Dev User	Allowed	Confirmed
ConfigRead	Anonymous (allow=false)	Not Allowed	Confirmed
ConfigRead	Anonymous	Allowed	Confirmed
ConfigRead	Demo Admin	Allowed	Confirmed
ConfigRead	Dev User	Allowed	Confirmed
CustomBookmarkCreate	Anonymous (allow=false)	Not Allowed	Confirmed
CustomBookmarkCreate	Anonymous	Not Allowed	Confirmed
CustomBookmarkCreate	Demo Admin	Allowed	Confirmed
CustomBookmarkCreate	Dev User	Not Allowed	Confirmed
CustomBookmarkDelete	Anonymous (allow=false)	Not Allowed	Confirmed
CustomBookmarkDelete	Anonymous	Not Allowed	Confirmed
CustomBookmarkDelete	Demo Admin	Allowed	Confirmed
CustomBookmarkDelete	Dev User	Not Allowed	Confirmed
CustomBookmarkRead	Anonymous (allow=false)	Not Allowed	Confirmed
CustomBookmarkRead	Anonymous	Allowed	Confirmed
CustomBookmarkRead	Demo Admin	Allowed	Confirmed
CustomBookmarkRead	Dev User	Allowed	Confirmed
CustomBookmarkUpdate	Anonymous (allow=false)	Not Allowed	Confirmed
CustomBookmarkUpdate	Anonymous	Not Allowed	Confirmed
CustomBookmarkUpdate	Demo Admin	Allowed	Confirmed
CustomBookmarkUpdate	Dev User	Not Allowed	Confirmed
DatabaseRead	Anonymous (allow=false)	Not Allowed	Confirmed
DatabaseRead	Anonymous	Allowed	Confirmed
DatabaseRead	Demo Admin	Allowed	Confirmed
DatabaseRead	Dev User	Allowed	Confirmed
DocumentationFormCreate	Anonymous (allow=false)	Not Allowed	Confirmed
DocumentationFormCreate	Anonymous	Allowed	Confirmed
DocumentationFormCreate	Demo Admin	Allowed	Confirmed
DocumentationFormCreate	Dev User	Allowed	Confirmed
DocumentationFormDelete	Anonymous (allow=false)	Not Allowed	Confirmed
DocumentationFormDelete	Anonymous	Allowed	Confirmed
DocumentationFormDelete	Demo Admin	Allowed	Confirmed
DocumentationFormDelete	Dev User	Allowed	Confirmed
DocumentationFormRead	Anonymous (allow=false)	Not Allowed	Confirmed
DocumentationFormRead	Anonymous	Allowed	Confirmed
DocumentationFormRead	Demo Admin	Allowed	Confirmed
DocumentationFormRead	Dev User	Allowed	Confirmed
DocumentationFormUpdate	Anonymous (allow=false)	Not Allowed	Confirmed
DocumentationFormUpdate	Anonymous	Allowed	Confirmed
DocumentationFormUpdate	Demo Admin	Allowed	Confirmed
DocumentationFormUpdate	Dev User	Allowed	Confirmed
GenesisDirectoryCreate	Anonymous (allow=false)	Not Allowed	Confirmed
GenesisDirectoryCreate	Anonymous	Not Allowed	Confirmed
GenesisDirectoryCreate	Demo Admin	Allowed	Confirmed
GenesisDirectoryCreate	Dev User	Not Allowed	Confirmed
GenesisDirectoryDelete	Anonymous (allow=false)	Not Allowed	Confirmed
GenesisDirectoryDelete	Anonymous	Not Allowed	Confirmed
GenesisDirectoryDelete	Demo Admin	Allowed	Confirmed
GenesisDirectoryDelete	Dev User	Not Allowed	Confirmed
GenesisDirectoryRead	Anonymous (allow=false)	Not Allowed	Confirmed
GenesisDirectoryRead	Anonymous	Not Allowed	Confirmed
GenesisDirectoryRead	Demo Admin	Allowed	Confirmed
GenesisDirectoryRead	Dev User	Not Allowed	Confirmed
GenesisDirectoryUpdate	Anonymous (allow=false)	Not Allowed	Confirmed
GenesisDirectoryUpdate	Anonymous	Not Allowed	Confirmed
GenesisDirectoryUpdate	Demo Admin	Allowed	Confirmed
GenesisDirectoryUpdate	Dev User	Not Allowed	Confirmed
GenesisInstall	Anonymous (allow=false)	Not Allowed	Confirmed
GenesisInstall	Anonymous	Not Allowed	Confirmed
GenesisInstall	Demo Admin	Allowed	Confirmed
GenesisInstall	Dev User	Not Allowed	Confirmed
GenesisRead	Anonymous (allow=false)	Not Allowed	Confirmed
GenesisRead	Anonymous	Not Allowed	Confirmed
GenesisRead	Demo Admin	Allowed	Confirmed
GenesisRead	Dev User	Not Allowed	Confirmed

UPDATE: I populated the rest of the test matrix by simply calling each agent without parameters and checking that it returned "status": "authenticated-with-insufficient-access". While many of these requests would fail anyway without these parameters, I would expect to see errorMessage set in this case, or data for the Read agents. I'll revisit this early next week and decide if I want to do more testing.

I have some automated tests, but I was limited in what I could test because of the Domino database dependencies. Ideally I would like to:

1. Automatically detect all agents (from agentProperties or by AgentBase superclass). I currently build this list manually.
2. Check that the agent has the expected roles populated. I am doing this currently
3. Check that the security object for the agent is an instance of SimpleRoleSecurity and that the roles match. This is where it starts failing

[piotrzarzycki21]

@JoelProminic I have deployed your changes and tested briefly how application behaves. It looks like it's responsive correctly on role_list changes. However I see that when I have in role_list following:

I'm getting in application list of:

Why is that ?

[JoelProminic]

Are you concerned about the "All" and "NotAnonymous" roles? These (as well as "Anonymous") are default roles that are separate from "role_list". I'll plan to add comments for this in the configuration documents when I regenerate the production database.

[JoelProminic]

My proposed default configuration:

Key	Default Value	Notes
allow_anonymous	false	This locks out all anonymous access by default. Setting this to true would allow access to bookmarks and documentation
ui_documentation_editable	false
ui_documentation_show_unid	false
ui_title	Super.Human.Portal
link_default_action	nomad
login_url	""
nomad_base_url	""	For an arbitrary production server, Nomad may not be configured, or it may be on a different server.
nomad_helper_url	""
role_list	Administrator
role_Administrator_users	""	User will need to manually add administrator users on production servers

I will then add a Genesis JSON file to Super.Human.Installer provisioners to modify the configuration for the demo servers:

Key	Default Value	Notes
allow_anonymous	true
nomad_base_url	https://nomadweb.%server%/nomad
nomad_helper_url	https://nomadweb.%server%/nomad/nomadhelper.html
role_Administrator_users	Demo Admin

[JoelProminic]

Here is the default configuration I settled on for the v1.0.0 release candidate:

        setConfigurationValue(localCopy, "allow_anonymous", "false", "Set to 'true' to allow all users access for the application. Not recommended for production environment.  See 'role_list' for more security settings.");
        setConfigurationValue(localCopy, "ui_documentation_editable", "false", "Set to 'true' to allow documentation to be edited in Getting Started page.");
        setConfigurationValue(localCopy, "ui_documentation_show_unid", "false", "Set to 'true' to show the universal ID for the Getting Started documents.");
        setConfigurationValue(localCopy, "ui_title", "Super.Human.Portal", "Customize the application title.");

        // additional options
        // Default action for bookmarks/links.  "nomad" or "notes"
        setConfigurationValue(localCopy, "link_default_action", "nomad", "Default action for bookmarks.  'nomad' to open in Nomad (default) or 'notes' to open in the Notes client.");
        setConfigurationValue(localCopy, "login_url", "", "Specify a custom login URL.  If no value is specified, use the default Super.Human.Portal login form.");
        setConfigurationValue(localCopy, "nomad_base_url", "", "Specify a custom base URL for nomad.  Generally this will end with '/nomad'.  If this is blank, Super.Human.Portal will default to https://nomadweb.<server>/nomad");
        setConfigurationValue(localCopy, "nomad_helper_url", "", "Specify a path to nomadhelper.html, which allows Nomad URLs to be opened directly in an open Nomad tab.  This is expected to be on the same server as Nomad.  If blank or missing, then Nomad links will open in new tabs, which will open the databaes in the original Nomad tab.");

        // default security logic
        setConfigurationValue(localCopy, "role_list", "Administrator", "A list of custom roles to define.  For each role here, define a 'role_%role%_users' document (see role_Administrator_users for an example).  The default roles do not need to be defined here:  All, Anonymous, NotAnonymous");
        // By default, disable all Administrator features
        setConfigurationValue(localCopy, "role_Administrator_users", "", "A list of users who should have Administrator access to Super.Human.Portal." + newline + 
                                                                         "Administrator features:" + newline +
                                                                         "- Install application" + newline +
                                                                         "- View installed appliations" + newline +
                                                                         "- Add additional Genesis Directories" + newline +
                                                                         "- Create/edit/delete bookmarks"
                );

        // by default, save logs to this database
        setConfigurationValue(localCopy, "log_server_default", "", "The server where the agent logs should be stored.  Multiple values are allowed - they will be attempted in order.  Leave empty to use the local server.");
        setConfigurationValue(localCopy, "log_dbname_default", "SuperHumanPortal.nsf", "The database where the agent logs should be stored.");