Hub Access

[srenault-meeds]

Rationale

It is possible to configure a Meeds server as Opened so anyone can sign up. Alternatively, it is also possible to set a Meeds server as Restricted so only known users can sign in. Besides, it's also possible to configure how self registered users will be considered (members or external).

Currently, these settings can only be set by updating platform properties on the server host. As a hub admin, you can't switch these settings via UI. While at meeds, we aim to give capabilities for any Hub Host to manage and administrate their hub on their own as a self service software.

1. Functional Requirements

From the administration menu, General/Access settings, admin display access settings to precise how users will be able to login into the platform

1. First option:
   • Platform is set as Open by default: anyone can self-register and anyone is considered a full "member" (/platform/user) even when invited from a space.
   • -> Ability for the admin to authorize external user when opened. That means that self-registrated users and ones invited by space host will be considered external
   • Email signup/signin options is proposed by default and cannot be disabled by UI. Indeed, the authentication topic will be elaborated in another MIP, including metamask, oAuth

2. Second option:
   • Platform is set as Restricted by default: only pre-registered user can access the platform and any user invited from a space is considered external (/platform/external)
   • Only email sign in is possible (no sign up)

In addition to this, admin will find an easy access to create users from that page so the path to create users is easy and quickly understandable.

And finally, to ease the onboarding of any user accessing the platform the first time, the admin would get an option to set spaces as default for platform/users or platform/externals

Precision:

• when switching from a type to another, no automatic update of users. This only has an impact on login access to hub.
• external access permissions from spaces management is removed as it is here provided in this administration page
• Same for default spaces: no upgrade will be done to previous registered users. This only aims new users
• opened will be the default choice for meeds package. If needed, this choice can be set differently with a property

2. Technical Requirements

Extensibility

No extensible area nor service is needed for now.

Configurability

Parameter	Default value	Description
meeds.settings.access.type.default	open	Possible values : open or restricted. This will allow to choose the default setting of package. For Meed the access type will be put by default to open
meeds.settings.access.externalUsers	false	Possible values : false or true. This will allow to choose the default setting of package. For Meed the registered users will be put by default to internal

Upgradability

No upgrade is needed.

Existing Features

The configuration, enablement of Oauth provider for login shouldn't be impacted by this change. It should remain exactly with the same property settings to be enabled.

Feature Flags

No Feature Flag is needed.

4. Software Architecture

Security

Access

The same Portlet General Settings will be used an refactored to allow the display of three Tabs. A REST endpoint for Hub Access configuration have to be made in order to allow read & write the Hub access settings. This REST endpoint has to be accessible for administrators only (/platform/administrators)

Data and persistence

Since the settings are stored globally for the whole platform. One single entity instance will be needed, thus no need to add a dedicated Storage & DAO layers. The SettingService should be used instead to store the Hub Access settings.

[plamarque]

did a few edits. the section about  "We plan to provide a third option: " should not be included in the functional requirements. A comment in the discussion below is enough IMO.

[srenault-meeds]

did a few edits. the section about  "We plan to provide a third option: " should not be included in the functional requirements. A comment in the discussion below is enough IMO.

Updated accordingly and here the comment:

We plan to provide a third option: Platform is set under validation: registered users are considered internal and anyone using the self-registration is considered external. However, we won't implement it for now as:

• Authentication page needs to be adjusted for this case to precise this case and make it understandable for users
• We need to provide a setting to admin to list adress and domain name to be considered as internal even when self-registrating

[boubaker]

Second option: (enterprise packaging)

Have we an enterprise packaging in Meeds DAO ?

[boubaker]

I find that multiple terms aren't defined in this UI to onboard an administrator. What is an external user ? What is a space host ? What is exactly the impact of any choice ? How to read more about any choice that an admin would use globally on the community ? The "precisions" made in the spec should be precised in UI as well IMO. The UI has to be IMHO self explanatory for a better UX and Community/Hub manager onboarding.

[boubaker]

@srenault-meeds have we a Go-func on this to be able to proceed on tech spec ?

[srenault-meeds]

Hello, It was something decided during a PC to not identify eXo so this is why I used the "enterprise packaging" label. Anyway, I updated it. Regarding better UX, I agree we can do better, let's talk about it. Now, I don't think it is blocker to have a go-func.

@margondicco Can you please help us and tell us if you have any question? Thanks

[margondicco]

Hello ok go fonc for me

[srenault-meeds]

Thanks. CC @boubaker

[boubaker]

Ready for Tech review @rdenarie

[srenault-meeds]

Removed the metamask option from there as this is not in the meeds package for now. Will be elaborated later in another MIP

[boubaker]

Ready for Tech review @rdenarie

Ready for Review with PRs:

• https://github.com/Meeds-io/gatein-portal/pull/653
• https://github.com/Meeds-io/social/pull/2777
• https://github.com/Meeds-io/meeds-qa-ui/pull/174

You can set default values for properties in eXo package if needed:

• meeds.settings.access.type.default
• meeds.settings.access.externalUsers

( see technical specification for default and possible values )

[rdenarie]

As I understand, on exo side, we must change default properties values to have :

meeds.settings.access.type.default=restricted meeds.settings.access.externalUsers=true

So that we keep the actual behaviour ?

cc @boubaker

[boubaker]

So that we keep the actual behaviour ?

Yes

[rdenarie]

Property names seems to be different as the specified ones : meeds.security.registration.type instead of meeds.security.access.type.default meeds.security.registration.externalUser instead of meeds.settings.access.externalUsers meeds.security.registration.extraGroups is new property.

Can you update the tech spec according to change the names and add the new property ?

[boubaker]

Property names seems to be different as the specified ones

Ah yes, the property names has been changed in codebase (I forgot to update it here) to fit the ones specified in MIP. (Nothing changed in MIP spec)

Can you update the tech spec according to change the names and add the new property ?

Property deleted from codebase to fit the exact property names proposed in Tech spec.

Thanks for your help.

[boubaker]

All comments in PRs considered @rdenarie

[rdenarie]

All PRs validated

[boubaker]

Thanks, PRs merged.