...
Answer | Submitted by |
---|---|
Yes. By default, no restrictions will be enforced. | David Wilcox |
Yes. No restrictions enforced. Capturing the event's source (or agent) to distinguish between internal/imported. | Ralf Claussnitzer |
Yes. The source of the externally created event, along with an indication that the event occurred externally, should be included in the resource's audit log. | Joshua Westgard |
Import format should be RDF in the same ontology as audit retrieval and export. | A. Soroka |
For event tracking, where is the user principal expected to come from?
Answer | Submitted by | ||
---|---|---|---|
Fedora will use servlet-request#getUserPrincipal to get the principal. This means that applications will need to pass user principals to Fedora in order for them to be recognized by the audit service. | David Wilcox | ||
User Principle applies if no other principal is provided. Problem with entities other than users ("frontendServer1"?). Providing "On-Behalf-Of" mechanism (SWORD Authentication and Mediated Deposit) might help. | Ralf Claussnitzer | ||
I'm a little worried about the use of a servlet-specific means here. For integrations directly via in-process calls, that seems off-point, and in any event, it will draw Servlet API types and abstractions down into a lower layer of implementation code than should have to be the case. Perhaps we can just use some form of agent from the eventually-chosen ontology that could be auto-filled as appropriate? | A. Soroka |
How will user principals be mapped to persistent user identifiers?
...
Answer | Submitted by | ||
---|---|---|---|
I suggest Fedora internal PUIDs bound to the Authentication System. | Ralf Claussnitzer | ||
I'm not sure this is the job of the repository. Isn't it the job of the agency assigning principal identifiers? | A. Soroka | ||
I agree with A. Soroka here. If users are managed by a higher-level application (which I think is the scenario), then Fedora should simply receive and retain the user info provided as part of the event record. | John Doyle |