Reject request when roleIDs not in context

[kulmann]

This PR enforces permission checks on all endpoints except:
1: GetAccount unconditionally
2: ListAccounts when the request payload has a non-empty query argument

With this, it is required to have roleIDs in the service handler function context.
a) for http requests we have a middleware in ocis-pkg that dismantles the x-access-token and writes the roleIDs into the context. Example:

ocis-accounts/pkg/server/http/server.go

Line 59 in 4598747

mux.Use(middleware.ExtractAccountUUID(

b) for grpc/http2 requests you could create the context manually. 🤷 We already do this in grpc tests in ocis-settings. There are security impairments connected to this, but those will be solved separately.

Known issue: glauth makes a ListAccounts grpc request with an empty search query, just after login. This breaks the login. When that is solved we will see failing CI, because the provisioning API (see ocis-ocs) uses basic auth, but ocis-proxy doesn't implement basic auth. Thus the access token doesn't get created.

outdated description

This is what should happen in the permission checks. No matter where the request is coming from (internal call from another service or external call that came through ocis-proxy) the service handler should reject the request when the required user context, in this case the roleIDs of a user, is missing.

We're facing three issues here:
1: ocis-proxy uses ListAccounts with a query for looking up a user: https://github.com/owncloud/ocis-proxy/blob/db95804af53dce6f73803ffa477e7e5eaef1573a/pkg/middleware/account_uuid.go#L24 This request to ocis-accounts happens with claims from a successful authentication. This step is about fetching the ocis account and building the user context which is required for all subsequent permission checks. I.e. in this state we can not run permission checks.

2: as already known, the enforced permission check from this PR breaks ocis-ocs when using basic auth. For an oidc scenario we just need to setup a middleware from ocis-pkg like we did in ocis-accounts:

ocis-accounts/pkg/server/http/server.go

Line 59 in 4598747

mux.Use(middleware.ExtractAccountUUID(

This middleware dismantles the x-access-token from the header of an http request and puts "useful information" (in our case account-uuid and role-ids) into the metadata context.

3: ocis-ocs uses ListAccounts with a query for looking up sharees when trying to share files/folders in ocis-web. At the moment we only have an account management permission. For this we also need a share permission, add it to the default user role and implement a permission check in ocis-accounts, next to the account management permission.

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[kulmann]

@butonic we need to solve this ListAccounts call coming from ocis-glauth that has an empty search query.

@individual-it @phil-davis when we solved that ^ we need your opinion on the impact of this for the usage of the provisioning API in the test suites.

[kulmann]

@butonic request from ocis-glauth against ocis-accounts with the empty query, which is now forbidden in ocis-accounts:

2020-09-03T18:49:17+02:00 ERR Could not list accounts error="{\"id\":\"com.owncloud.api.accounts\",\"code\":403,\"detail\":\"no permission for ListAccounts\",\"status\":\"Forbidden\"}" basedn=dc=example,dc=org binddn=cn=konnectd,ou=sysusers,dc=example,dc=org filter=(objectClass=posixaccount) query= service=glauth src={"IP":"::1","Port":61703,"Zone":""}

[kulmann]

More context:

2020-09-03T18:59:11+02:00 DBG Bind request basedn=dc=example,dc=org binddn=cn=konnectd,ou=sysusers,dc=example,dc=org service=glauth src={"IP":"::1","Port":62007,"Zone":""}
2020-09-03T18:59:11+02:00 DBG using query query={"conjuncts":[{"field":"bleve_type","term":"account"},{"field":"on_premises_sam_account_name","fuzziness":0,"match":"konnectd","prefix_length":0}]} service=accounts
2020-09-03T18:59:11+02:00 DBG result result={"facets":null,"hits":[{"id":"820ba2a1-3f54-4538-80a4-2d73007e30bf","index":"/var/tmp/ocis-accounts/index.bleve","score":3.4921022015832683,"sort":["_score"]}],"max_score":3.4921022015832683,"request":{"explain":false,"facets":null,"fields":null,"from":0,"highlight":null,"includeLocations":false,"query":{"conjuncts":[{"field":"bleve_type","term":"account"},{"field":"on_premises_sam_account_name","fuzziness":0,"match":"konnectd","prefix_length":0}]},"search_after":null,"search_before":null,"size":10,"sort":["-_score"]},"status":{"failed":0,"successful":1,"total":1},"took":87135,"total_hits":1} service=accounts
2020-09-03T18:59:11+02:00 DBG found account AccountEnabled=true CreatedDateTime=null DeletedDateTime=null Description= DisplayName="Kopano Konnectd" GidNumber=15000 Id=820ba2a1-3f54-4538-80a4-2d73007e30bf Identities=null IsResourceAccount=false Mail=idp@example.org MemberOf=[{"id":"34f38767-c937-4eb6-b847-1c175829a2a0"}] OnPremisesDistinguishedName= OnPremisesLastSyncDateTime=null OnPremisesSamAccountName=konnectd OnPremisesSecurityIdentifier= OnPremisesSyncEnabled=false OnPremisesUserPrincipalName= PreferredName=konnectd UidNumber=10000 service=accounts
2020-09-03T18:59:11+02:00 DBG Bind success binddn=cn=konnectd,ou=sysusers,dc=example,dc=org service=glauth src={"IP":"::1","Port":62007,"Zone":""}
2020-09-03T18:59:11+02:00 DBG Search request basedn=dc=example,dc=org binddn=cn=konnectd,ou=sysusers,dc=example,dc=org filter=(objectClass=posixaccount) service=glauth src={"IP":"::1","Port":62007,"Zone":""}
2020-09-03T18:59:11+02:00 DBG parsed query basedn=dc=example,dc=org binddn=cn=konnectd,ou=sysusers,dc=example,dc=org filter=(objectClass=posixaccount) qtype=users query= service=glauth
2020-09-03T18:59:11+02:00 ERR Could not list accounts error="{\"id\":\"com.owncloud.api.accounts\",\"code\":403,\"detail\":\"no permission for ListAccounts\",\"status\":\"Forbidden\"}" basedn=dc=example,dc=org binddn=cn=konnectd,ou=sysusers,dc=example,dc=org filter=(objectClass=posixaccount) query= service=glauth src={"IP":"::1","Port":62007,"Zone":""}

First request fetches the kopano user (successfully). The second request has an empty search query and therefor fails.

[butonic]

tricky :-)

1. konnectd uses an entryid, which is the fetched user dn, as the base dn

2. after checking that the search basedn, in this case the user dn, is in scope of the configured basedn glauth drops the search base dn and uses the configured one. the scope is base so the request should actually only fetch the single entry.

• ocis-glauth needs to parse the search basedn and extract the userid so it can create the correct filter and only retrieve the requested account.