Server: Customised federated cloud id to prevent something like [email protected]@nextcloud.mydomain.ltd

[tigre-bleu]

This is a repost of an issue that I originaly opened on https://github.com/owncloud/core/issues/23412 but that did not get a definitive answer. Maybe with nextcloud it would be different :)

This is a thought about the federated cloud Id.

I have a LDAP for all my users and in every hosted service, the user name is mapped to the email. Let's say john.[email protected]

I configured a nextcloud instance on nextcloud.mydomain.ltd with LDAP and the users can successfully use it using their user name john.[email protected]

So far so good.

However, when they want to share their federated cloud id, they have to share john.[email protected]@nextcloud.mydomain.ltd which is quite non-intuitive as:

1. There are 2 @ in the thing
2. mydomain.ltd is repeated twice
3. Everywhere their username is john.[email protected] so why not here?

I completely understand why the federated cloud id is currently defined as it is. However there may be additional options that could be added. For instance, why not having something like this:

1. Add an option for customised federated id so that the administrator can configure it to something like john.[email protected]
2. Administrator adds something on his webserver like http://mydomain.ltd/nextcloud-federated-sharing.xml. In this file, the mapping with the real nextcloud url and the real username definition is performed. For instance:

<nextcloud>
<url>nextcloud.mydomain.ltd</url>
<username>
<right-part>true</right-part> 
</username>
</nextcloud>

About <right-part>:
-If false: john.doe would be the username from john.[email protected].
-If true; username would be john.[email protected].

1. When a foreign owncloud user would try to share something, it would try to see if there is a http://mydomain.ltd/nextcloud-federated-sharing.xml.
   -If one is found then it would try sharing using the real federated id reconstructed from the xml: john.[email protected]@nextcloud.mydomain.ltd
   -If none is found then use the regular federated sharing

This is a just a first thought that is quite similar to the autoconfig of email account configuration. Maybe it would also be possible to use DNS SRV records to do this.

Let me know what you think :)

[MorrisJobke]

@schiessle wasn't there some discussion ongoing already?

[schiessle]

Yes, we discussed this already and it sounds link a interesting idea. The difficult part is that someone would need to maintain the mapping and make sure that it is always up-to-date.

[schiessle]

I think @icewind1991 had some similiar ideas...

[tigre-bleu]

The difficult part is that someone would need to maintain the mapping and make sure that it is always up-to-date.

True but this is already the case in some way for uid mapping in the LDAP configuration.

[AMDG2]

I think the resolving can be done using well-known URIs

For example if original federated cloud id is : [email protected]@nextcloud.example.com and we want to use : [email protected]

We should : add a .well-known redirection like this : https://example.com/.well-known/federated-cloud -> https://nextcloud.example.com

So when we try to share to [email protected], nextcloud behave like this :

1. Try to connect to a federated cloud instance at example.com with user user
2. If not found try to find a .well-known redirection
3. If redirection found, try to connect with user user
4. If user user not found, try with user [email protected]

This way no user mapping is needed, only some basic redirection that already works with DAV.

What do you think ?

[tigre-bleu]

It looks quite simple and efficient indeed.

[schiessle]

This all sounds good and like a really interesting approach. But there is one open question for me:

• How should we decide which federated cloud ID we show in the users personal settings? Right now we always construct it with <user>@<nextcloud>. If we enable this well-known redirecty it could be only user or even something completely different. For example I would like to use my email address and put the well known re-direct to my personal domain.

Any idea to solve this problem? Should we just allow people to set their own federated cloud id in the personal settings?

[schiessle]

If we solve the remaining questions I would love to add it to the road map for Nextcloud 12. Of course I would also be happy if some of you would like to work on it 😃

[AMDG2]

I think this should be decided by the Nextcloud administrator.

The choices can be:

• Full id ([email protected]@nextcloud.example.com)
• Full username, custom domain ([email protected]@example.com)
• Short username, full domain ([email protected])
• Short username, custom domain ([email protected])

Short username can be determined like this:

• If there is an @ inside the username
  
  
  
  • Split the username on the first @ and the short username is the first split result
  
  
• Else
  
  
  
  • The short username is the full username
  
  

The domain should be customizable by the administrator. Because he can setup the .well-know redirection with any domain he owns.

Perhaps a check should be added in the administration panels to alert the administrator when the customized domain doesn't redirect to the nextcloud instance.

I would like to work on that, but my last year of engineering school is taking too much time !

[gauthierl]

Another possibility is to use a DNS record (SRV) like this :

_nextcloud._tcp.example.org. 3600 IN SRV 0 10 443 nextcloud.exemple.org.

[schiessle]

@icewind1991 I think this goes in the same direction we just discussed

[tigre-bleu]

Are there any ongoing design discussion on this topic?

[DanScharon]

is there any progress regarding this concept?

[JoeKun]

I would really love to see this feature request get some traction. I think it would be great if Nextcloud users were really able to use their email address as their federated cloud ID (at least for users who have control over the domain name used in their email address). This would allow such users to have a stable federated cloud ID, regardless of the Nextcloud server they're currently using to store their data.