University of North Carolina at Chapel Hill

As the developer of a disciplinary research data portal, I want to use the central Fedora repository on campus and its web API. However, many objects in the repository are restricted. As a trusted third-party application, I would like to forward user credentials, such that authorization for my portal is identical to authorization for the main repository site. Without this I cannot connect to a repository containing protected objects unless I duplicate authorization in all my front-end applications, in whatever language, etc.. (This duplication of authorization would make my application far less trustworthy.)

As a repository manager, I need to delegate repository work to other library staff. I need a way to create separate spans of control within which sets users have the ability for perform work.

Repositories define all kinds of metadata fields/properties that constitute workflow metadata, such as publication status or embargo date. These properties will vary by application. In an extensible authorization mechanism, we will be able to make our permissions contingent upon arbitrary metadata linked to the object in some way. In some cases these may even be properties that are indirectly linked, such as work flow metadata on a container or parent object. In the UNC case, we use a publication boolean property that is inherited through the repository tree. We also have embargo dates that are inherited. This gives us powerful management features for whole collections or complex objects.