Who is allowed to create a user on my server?

Hi,

My name is Bob, and I'm the server of organization A. As we use the WebID-OIDC spec, a distant user logged in on her server can supposedly create an account at my place.

Under which conditions?

Does every WebID-OIDC user that is logged in somewhere on the web can create an account at my place and log into me?

Please, elaborate further.

mentioned in issue #202 (closed)

By Alexandre on 2020-01-15T16:48:50 (imported from GitLab project)

added Question + 1 deleted label

After review, it looks like a Feature Request to me.

I'm not sure if I understand correctly the question, but that may be already handled by DjangoLDP accounts. Today if you send a request to another djangoLDP server, that server creates an account for you. You can't log in directly on that server, but OIDC works.

Cool news.

The question is: from which servers are users allowed to create an account on mine via WebID-OIDC?

We can probably have it fully open for now but quickly it won't be sustainable I believe. You don't want the whole world to be able to create an account on your server I believe.

There probably is such a thing as a members only level of access, meaning those who have an account. And if every WebID-OIDC provider can then duplicates its user account onto my server, members only always equals to the whole world.

I hope I clarified my question...

By Alexandre on 2020-01-16T06:57:16 (imported from GitLab project)

Actually as a user you don't create an account. You log in though oidc. And I believe in the general case we want to allow anyone to make an oidc request.

The account creation is a technical thing, because the server has a local representation of all remote resources, including users. That's how your able to make links with remote resources, like adding permissions to remote users, for example.

Sylvain is right.

We can add the fact that actually anyone can log in a federated server. But It's easy to add some rule on some server to forbid a distant user to login, using any criteria (banned user, banned server or anything else)

By Jean-Baptiste on 2020-01-16T08:42:03 (imported from GitLab project)

currently DjangoLDP uses username for the linked id though, which causes problems with the slug ... so I think for this to work it will need to be refactored?

https://git.happy-dev.fr/startinblox/applications/sib-app/issues/287#note_56199

I understood your answers, and it makes sense.

I will ask my question differently, just so we go to the bottom of the use case.

I am now the Happy Dev network. I have a dozen of federated servers. Among those, I'd like any member to be able to join a public Circle.

However, I don't want Russian prostitutes from the Hot Russians Queens network to enter my Circles. They are not welcome. Do we have a mechanism today that allow my servers to block their connections requests?

By Alexandre on 2020-01-16T14:29:46 (imported from GitLab project)

when you are a foreigner make you can click "request to join circle" or even "request to join network" ... if your server is trusted the request goes straight to the circle's admins with your user, if it isn't your server makes a request to the admins of the server you are connecting?

(in this design, does happy-dev-paris speak for all of the happy-dev-network, or do you need to authenticate with each individually?)

From these discussions I propose the following changes:

• foreign users should not have their id stored in the username field. It should be stored in its own field, and a unique username generated startinblox/applications/sib-app#287 (comment 56199)
• either a user is marked as a foreigner and given restricted access permissions, or authenticated users in general have restricted permissions unless they are given to a group (e.g. happy-dev-ais, Parisien)

I don't thing preventing the user request is the way to go for your use case. I think it's typically a user choice, and WebACLs should be used here. In other words, the server should allow connection from anyone, but there should be permissions on who is allow to join a circle. And there should be a Happy Dev group allowed.

okay I agree, I edited my comment below to match

It is not crystal clear to me but if that is enough of a spec to @calummackervoy and @balessan: I'm at peace with it :)

By Alexandre on 2020-01-16T15:00:39 (imported from GitLab project)

What should be the form of a username and a slug then?

I'm not sure to get your second point. I don't see how there should be something specific about "foreigner" users when it comes to permissions.

I think a username can be anything unique that matches the validation of the server, and that it's okay for the slug to use the username, if the user's web-id is stored on a different field

the second point is on the assumption that bob from Hot Russians Queens is permitted to make an account, but we might not want them to be permitted to join a public circle and start adding members... I guess circle permissions will need to become more granular than just "Public" and "Private"

yes but the slug should be somehow readable, right?

I agree for the permission issue, but it's not a DjangoLDP issue. Unless there is some sort of limitation that prevents what we need?

Do we have a mechanism that assigns permissions based on your OIDC provider?

By Alexandre on 2020-01-16T15:28:06 (imported from GitLab project)

@sylvain DjangoLDP Account has validation for username already https://git.happy-dev.fr/startinblox/djangoldp-packages/djangoldp-account/blob/master/djangoldp_account/models.py#L36

@alexandre no I don't think so, permissions are defined via the model like

class Meta:
    authenticated_perms: ['view', 'add']

or in a permission class by overriding user_permissions(...) and applying this to the model

Do we manage to come up with a spec for that?

By Alexandre on 2020-01-16T15:37:15 (imported from GitLab project)