Alliance/corp allow only lists

ryanrolds commented 2 weeks ago

SSO is handling authenciation, but it currently lets anyone authenticated to create maps. This makes sense in a multi-tenant context, but in when self-hosting we want to a limit access to a list of approved alliances/corps.

I'm considering adding env vars that contain a comma-sepeated list of corp/alliance ids. When either of the allow lists are set, a middleware in the app forwards authenticated users not in the allow list to a themed "forbidden" page.

Thoughts? Better ideas?

DmitryPopov commented 2 weeks ago

We actually have implemented invite only users. So you can limit mapper for everyone usage on a character registration stage.

DmitryPopov commented 2 weeks ago

I can provide instructions how to enable it, if it'll work for you. So only users with a proper invite-link (should be generated by admin user) will be able to authorise in mapper.

ryanrolds commented 2 weeks ago

I'm aware that there is map-level access control. I'm looking for application-level access control. I want anyone that authenticates that isn't a member of a corp or alliance to only see a styled 403 page. I don't want them to have the ability to access any pages that are not absolutely nesseccary. And I don't want them to be able to create maps or glean any intel from data inside of the tool.

DmitryPopov commented 2 weeks ago

I'm aware that there is map-level access control. I'm looking for application-level access control. I want anyone that authenticates that isn't a member of a corp or alliance to only see a styled 403 page. I don't want them to have the ability to access any pages that are not absolutely nesseccary. And I don't want them to be able to create maps or glean any intel from data inside of the tool.

You can setup invite-only access to application authorization, so no one without proper link can access your server instance.

DmitryPopov commented 2 weeks ago

To enable invite-only access you should set next variable in wanderer-conf.env: WANDERER_INVITES=true

After that you should be able to generate invite link on admin page

ryanrolds commented 2 weeks ago

I've set that env var and I've yet to see any change in the UI that would allow me to create an invite-url. Looking at the source, I suspect the showing of the invite card is also tied to additional wallet id/secret. I've not set any of those env vars as there purpose or contents is unclear.

ryanrolds commented 2 weeks ago

If I'm understanding things correctly, with the invite URL they could make maps and poke around in the application. I would like to deny access to the entire application if they are not in an allowed corp/alliance.

DmitryPopov commented 2 weeks ago

If I'm understanding things correctly, with the invite URL they could make maps and poke around in the application. I would like to deny access to the entire application if they are not in an allowed corp/alliance.

Yep, for your purposes it'll be better to have a kind of white-list of allowed alliance/corp ids, but it'll be required to support/check it on many places. We can add functionality to block/delete some characters from server, so invite link valid for 24h, blocked users without proper invite link can't authorize/login to application, so they won't be able to manage/create any maps.

ryanrolds commented 2 weeks ago

Does the allow/deny list need to be checked in more places than initial token exchange and token refreshes?

If the alliance is hundreds/thousands of players, I would expect handing out time-limited invites to be a pain.

With the invite approach, if a character is removed from the alliance, what happens? Can they still make maps if they accepted the invite URL? If so, does that mean that anyone removed from the alliance must also be banned from Wanderer manually to prevent the ability to create maps?

DmitryPopov commented 2 weeks ago

Does the allow/deny list need to be checked in more places than initial token exchange and token refreshes?

If the alliance is hundreds/thousands of players, I would expect handing out time-limited invites to be a pain.

With the invite approach, if a character is removed from the alliance, what happens? Can they still make maps if they accepted the invite URL? If so, does that mean that anyone removed from the alliance must also be banned from Wanderer manually to prevent the ability to create maps?

Agree, this approach won't work for large allicances/corps. The checking for white-listed corp/alliances can be done after we fetch character data from Eve API only. So it'll looks like user registered -> waiting some time to sync ally/corp info -> apply white-list restrictions.

We have a several possible cases here:

users can have more than 1 characters registered, some in white listed corp/ally, some in own/other - should we check if all user character not in some ally?
while fetching information from EVE API there are still a small chance to create a new map on server

I'd suggest introducing a white-list of characters who allowed to create maps in this case, so application administrators can add/remove registered character(s) from/to it. I guess it shouldn't be a lot maps owners on a custom server for 1-2 alliances.

ryanrolds commented 1 week ago

users can have more than 1 characters registered, some in white listed corp/ally, some in own/other - should we check if all user character not in some ally?

Good question. People have multiple accounts and characters. If a subset of the user's characters are allowed, only the allowed characters should be tracked. If they sign-in with an unallowed character it should probably show up in their list, but be flagged in the UI as not permitted.

I suspect larger corps/alliances are going to want to be able to all the characters grouped by accounts to search for dumb spys. If the alliances is savey they will be ingesting access logs and comparing IPs as part of their standard operating procedure.

while fetching information from EVE API there are still a small chance to create a new map on server

A race conditoin in the auth process? OAuth completed but the character data hasn't been fetched?

I'd suggest introducing a white-list of characters who allowed to create maps in this case, so application administrators can add/remove registered character(s) from/to it. I guess it shouldn't be a lot maps owners on a custom server for 1-2 alliances.

I agree. I can see agrument to tie admin access to roles in-game rather than a service-level list.

Would introducing a middleware that is only added to the stack when a list is defined that checks their session for an allowed character work? I'm pushing for something application level and ideally high up on the routing stack because I assume there are going to be bugs that unintentionally leak information and the higher up the middleware stack the more likely they won't be able to access any of the endpoints/handlers that return data.

DmitryPopov commented 1 week ago

Would introducing a middleware that is only added to the stack when a list is defined that checks their session for an allowed character work?

It should work that way, but for now looks not clear enough. Mb we can do more simple approach to check ally/corp ID as you initially suggested, and not allow users without at least 1 character inside particular white-listed ally/corp membership to access any services.

So how can I see it:

user add 1-N characters
by default registered characters don't have any corp/ally info (it's not fetched immediately/Oauth returns only character eve ID/tokens), but we start fetching it after registration
if white-list set -> we check if some of registered user characters corp/ally in it
if white-list set -> we allow map creation (and other actions with maps) only to users with at least one character allowed (in white-list corp/ally)

So that way we block any actions for users who have characters with empty/wrong ally/corp set only.

ryanrolds commented 4 days ago

Makes sense to me. I will look implementing it.

wanderer-industries / wanderer

Alliance/corp allow only lists #26