問題描述
創建僅對給定數據庫具有權限的用戶 (Create user that has permission only to given database)
我正在嘗試在 MarkLogic 中創建對給定數據庫具有權限的用戶。我從 MarkLogic 文檔頁面閱讀了 安全指南,發現您可以對給定的 URI、集合或功能。
集合的權限可以幫助我將數據庫中的給定集合標記為僅對給定的用戶集可讀,但其他用戶仍然可以創建和修改不同集合中的文檔(或創建沒有集合的文檔)。
例如
我有兩個數據庫:
- Test
- Test2
還有兩個用戶:
- UserTest
- UserTest2
我如何設置 UserTest
對數據庫 Test
具有讀取/更新/插入/執行權限並且不能修改或讀取任何數據庫的權限Test2
?
參考解法
方法 1:
Each database can be associated with a dedicated security database. The way you describe your use case ("UserTest will have permissions read/update/insert/execute on database Test and can't modify or read anything database Test2"), you might want to consider dedicated security databases for the Test and Test2 databases.
The other way would be to use different document permissions for roles for the two databases. You can set read/update/insert/execute permissions at document level for a given role at insert time, or change them with xdmp:document‑add‑permissions() (retains previous permissions) or xdmp:document‑set‑permissions() (overrides previous permissions) after insert. For instance, you could have a role Test‑Reader for database Test and a role Test2‑Reader for database Test2, and ensure that (1) your UserTest user has the Test‑Reader role (but not the Test2‑Reader role), and (2) that all documents inserted into the Test database pair the read capability with the Test‑Reader role (but not the Test2‑Reader role) etc. (Same for the other capabilities.)
If controlling this explicitly sounds like a lot of work, note that default document permissions can be declared to apply implicitly both at the user and at the role level.
Finally, if you set no permissions at all during document insert (and if no implicit/default permissions are defined at user or role level), only users with the admin role can read/update/insert/execute.
Here's the relevant section for document permissions from the Understanding and Using Security Guide: https://docs.marklogic.com/guide/security/permissions#id_85471
方法 2:
There is no user‑level specifications for a database. But keep in mind, a database is not accessible on its own ‑ it is accessible by way of an application(s) which is linked to particular database. Unless you allow people to run eval and allow them to eval against another database, then you application will keep people within the specified database. (Note: ML8 Advanced HTTP server changes this a bit because you can switch database on‑the‑fly per request‑ but the rules about being stuck to a single database still stands).
The only other item I think is useful to you is the ability to define which URI prefixes a user can write to, but that does not negate the fact that the application level decided which DB is being accessed.
(by Kamil Budziewski、Markus Flatscher、David Ennis)