Skip Ribbon Commands
Skip to main content

Skip Navigation LinksDocDB Primer for Permissions and URLs

Not on the right page? Go back to the DUNE DocDB "how to" page​.

​​​​Three ​method​​​​s for accessing d​​ocum​​​ents in DocDB


DocDB houses both protected documents and public documents. If you only want to see public documents, click "Public" under Accessing DocDB. No password is requrired for these.

If you want to see documents that have any level of protection, you will need to go in either with a username and password (click "Private") or a gold-cert-50.png certificate (click "Certificate Version of DUNE DocDB").

Th​e URL for a document in Doc​​DB may ​​​take different forms!

Once you are in, the URL reflects the way that you got in: 

    • Public
    • Private
    • Certificate

This is important because, for example, if you give somebody a URL to a document with the "https" and "440", and they don't use a certificate, they won't get in. Similarly, if their DocDB session is already open with certificate access and in a different window they click on a "441" link, they'll be asked for a username and password.

Near the bottom of this page, we describe more ways the URL can vary; you can link to a document or to a file within a document, you can specify an "as of" date or a version...

How do permissi​​ons on document​s work? ​​ R​​emember: username/password access came first...

A key to remember is that the username/password method (with the 441" URLs) came first, and certificates came later, so permissions are based around usernames. Also remember, these are SHARED usernames associated with defined access groups.

Permissions are set individually for each document (i.e., each number) such that certain access groups can view only or view and modify the document.  (A given DocDB document/number may contain multiple files; the files share the permissions set for that document.)

Note that each version of a document can have separate metadata and therefore separate permissions.

dunedocdbuserhierarchy.pngHierarchy of Permissions:

DocDB uses access groups (each associated with a shared username) that are structured hierarchically, with "dominant" and "subordinate" groups. See graphic, at left.

Each DocDB document specifies two levels of permissions in terms of groups: which groups can view, and which can modify.

If you log in under a group that has subordinates, you have permissions to see and/or update any document that the subordinate group can, plus you can see and/or update documents with permissions set specifically for your (more dominant) group

It's helpful to know that the groups dunepm and lbnfpm ("pm" is for "project management") are both dominant to dune, and that dune is dominant to both the review and doe (not shown) groups.

For most people, a certificate only needs to be set for the most dominant group they will need, usually dune. (See "Now, what if you have a certificate?" below.) Since the hierarchy is multi-threaded, a few people (more likely those associated with the projects) will need to have their certificate associated with more than one group.

Now, ​what if ​​you have​ a gold-cert-50.pngcertificate? 

Your certificate is paired with an access group, and using it is equivalent to logging in with the associated (shared) username and password. Certificates can be paired with multiple access groups; this is useful when the groups have some non-overl​apping, or parallel, permissions (e.g., dunepm and lbnfpm).

Your certificate uniquely identifies you to the system, and it can be paired with whatever set of access groups YOU require. You will have permissions to everything that any of these groups can access.​

The CILogon Certificates that we recommend expire after 13 months, then you need to renew.

You never have to enter a password EXCEPT when you click on a ":441" style link... beware!

​More ways the U​​RL can vary...

You can link to a document (number), to a specific file, or to either as of a particular date. Or to a specific version of either. This is documented in the generic DocDB instructions under Referring to Your Document and Files. Here are some examples.

In these examples, we use the username/password flavor of the URL and a sample document 662 that contains a PDF file (we'll pretend that it's not public!).