Repository navigation
Customised federated cloud id to prevent something like [email protected]@owncloud.mydomain.ltd #23412
Description
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 [email protected]
I configured an owncloud instance on owncloud.mydomain.ltd with LDAP and the users can successfully use it using their user name [email protected]
So far so good.
However, when they want to share their federated cloud id, they have to share john.doe@[email protected] which is quite non-intuitive as:
- There are 2 @ in the thing
- mydomain.ltd is repeated twice
- Everywhere their username is [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:
- Add an option for customised federated id so that the administrator can configure it to something like [email protected]
- Administrator adds something on his webserver like http://mydomain.ltd/owncloud-federated-sharing.xml. In this file, the mapping with the real owncloud url and the real username definition is performed. For instance:
<owncloud>
<url>owncloud.mydomain.ltd</url>
<username>
<right-part>true</right-part>
</username>
</owncloud>
About <right-part>:
-If false: john.doe would be the username from [email protected].
-If true; username would be [email protected].
3. When a foreign owncloud user would try to share something, it would try to see if there is a http://mydomain.ltd/owncloud-federated-sharing.xml.
-If one is found then it would try sharing using the real federated id reconstructed from the xml: john.doe@[email protected]
-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 :)
Activity
MorrisJobke commentedon Mar 21, 2016
This was lengthy discussed by @jancborchardt, @schiesbn and @DeepDiver1975 in #14218
See #14218 (comment) and #14218 (comment)
I will close this, because it has huge architectural issues and they need to be addressed beforehand and will resolve this then automatically.
MorrisJobke commentedon Mar 21, 2016
Or am I wrong here @schiesbn @DeepDiver1975 @jancborchardt
@tigre-bleu Sorry to have this closed that fast, I guess I also could be wrong.
MorrisJobke commentedon Mar 21, 2016
And @karlitschek of course
karlitschek commentedon Mar 21, 2016
so the strategy is that the username becomes a purely internal id which is invisible to the users. because of that it doesn't matter what it is and that it can't be changed. in the ui we always use the display nme which can be changes. login will be possible with email which can be changed. We could create the option for custom federation id which can be changed. not sure it is worth the work at the moment because with proper autocompletion the users never see the federation id either.
schiessle commentedon Mar 21, 2016
We already had this as a PR. User could define a alias for their federated cloud ID, so they could customized the ID to have it the way they wish. But the majority didn't liked it, so we didn't merged it. You can see the PR and the discussion by following Morris links.
tigre-bleu commentedon Apr 1, 2016
I read the discussion in #14218
This is linked to this issue, but not completely.
I was not suggesting that the user can choose its own ID, but rather that the admin defines a policy for cloud-id re-construction. This is easier to implement as the real user id would still be managed in the current way.
iaean commentedon Apr 13, 2016
👍 Same issue, here.
But my LDAP users getting a RFC-4122 V1 UUID as Federated Cloud ID. Local users behave as expected.
[email protected]/oc[email protected]/oc(as documented)I completely agree with @tigre-bleu and for the most part with @schiesbn.
[email protected]/ocis nothing a user likes to publish. But it seems to be sufficient to give the OC admin better information about FedID creation and configuration, especially if LDAP is deployed.I'm a little bit in doubt about @karlitschek's idea to hide the FedID from the user completely. FedID seems to be something a user wants to publish. The more users are publishing their FedID the more and faster the federation idea is spotlighted...
Best regards
WicharnT commentedon Jul 10, 2018
I'm found same issue,
owncloud.mydomain.ltd trueI'm can't see directory config below
Atom.t
stale commentedon Sep 21, 2021
This issue has been automatically closed.