How to restrict user logins properly

[xoxys]

Is your feature request related to a problem? Please describe.

Scenario: oCIS with external IDP + LDAP

As an admin, I want to restrict oCIS login to one/multiple dedicated LDAP groups, and it needs to work for the Web client as well as all native clients.

Describe the solution you'd like

Using LDAP user filter

What I have tried so far is to control this via the LDAP user filter in oCIS. This way, oCIS will only "see" users from those groups and only those users can log in:

LDAP_USER_FILTER=(|(memberof=cn=admin,ou=groups,dc=example,dc=org)(memberof=cn=ocis-user,ou=groups,dc=example,dc=org))

Problems:

• Users not matching LDAP_USER_FILTER but allowed to log in to the IDP will end up in an ugly redirect loop
• Sharing is only possible with available users, there might be a use case where sharing with disabled/temp locked users should be possible which is not possible using this way

Using role mapping in the external IDP

From the Keycloak docs:

user role mapping
A user role mapping defines a mapping between a role and a user. A user can be associated with zero or more roles. This role mapping information can be encapsulated into tokens and assertions so that applications can decide access permissions on various resources they manage.

This way LDAP groups can be mapped to oCIS roles (user, admin, space-admin, etc.) and only users with a valid role will be able to log in. AFAIK, oCIS can't handle it yet. As a ref how it could work, we use this with Grafana already as described in the docs https://grafana.com/docs/grafana/latest/setup-grafana/configure-security/configure-authentication/generic-oauth/#role-mapping

Using Authorization in the external IDP

https://www.keycloak.org/docs/latest/authorization_services/

This way requires a confidential OIDC client, which is AFAIK not supported for Web.

[rhafer]

Is your feature request related to a problem? Please describe.

Using LDAP user filter

What I have tried so far is to control this via the LDAP user filter in oCIS. This way, oCIS will only "see" users from those groups and only those users can log in:

LDAP_USER_FILTER=(|(memberof=cn=admin,ou=groups,dc=example,dc=org)(memberof=cn=ocis-user,ou=groups,dc=example,dc=org))

Problems:

* Users not matching `LDAP_USER_FILTER` but allowed to log in to the IDP will end up in an ugly redirect loop

* Sharing is only possible with available users, there might be a use case where sharing with disabled/temp locked users should be possible which is not possible using this way

Yeah users not matching the filter will be completely invisible to ocis. But this is how the LDAP_USER_FILTER setting was supposed to work. Without the endless login loop obviously.

Using role mapping in the external IDP

[...]

This way LDAP groups can be mapped to oCIS roles (user, admin, space-admin, etc.) and only users with a valid role will be able to log in. AFAIK, oCIS can't handle it yet.

Right. But we'll get there eventually.

As a ref how it could work, we use this with Grafana already as described in the docs https://grafana.com/docs/grafana/latest/setup-grafana/configure-security/configure-authentication/generic-oauth/#role-mapping

[xoxys]

• Users not matching LDAP_USER_FILTER but allowed to log in to the IDP will end up in an ugly redirect loop

Compose file to reproduce:

---
version: "3.7"

services:
  ocis:
    image: owncloud/ocis:2
    entrypoint:
      - /bin/sh
    # run ocis init to initialize a configuration file with random secrets
    # it will fail on subsequent runs, because the config file already exists
    # therefore we ignore the error and then start the ocis server
    command: ["-c", "ocis init --insecure true || true; ocis server"]
    environment:
      OCIS_LOG_LEVEL: info
      IDM_ADMIN_PASSWORD: "admin"
      IDM_CREATE_DEMO_USERS: "true"
      USERS_LDAP_USER_FILTER: "(!(uid=einstein))"
    volumes:
      - ocis-config:/etc/ocis
      - ocis-data:/var/lib/ocis
    restart: always
    ports:
      - "9200:9200"

volumes:
  ocis-config:
  ocis-data:

[kulmann]

Tried to debug this yesterday and got a clue to some extend... not yet fully understood. But most important: web simply doesn't support the combination of valid idp-session + no ocis-session, yet. Needs to be implemented.
Still, I only see a kind of UI glitch, which is a redirect loop between login-page and accessDenied-page. So the user doesn't have access to any data at any time. I wouldn't say that this is a p2.

[xoxys]

So the user doesn't have access to any data at any time

Just to clarify it a bit, from my side this was never intended to be a critical or security related issue, but IMO to have a properly working and documented way how to limit access to a specific group of users is a very basic must have feature to me as nearly nobody wants to give access to all users of an organization to a tool.

[micbar]

@kulmann transfer to web?