search

sul-dlss-deprecated / triannon

Rails engine for working with storage of OpenAnnotations stored in Fedora4
Other
13 stars 1 forks source link

triannon receives webauth info in request #169

Closed ndushay closed 9 years ago

ndushay commented 9 years ago

If we know

then we can write the code in Triannon that

ndushay commented 9 years ago

@azaroth42 - want to add to this? Write / move a spec from someplace to this ticket?

ndushay commented 9 years ago

re authentication: https://itservices.stanford.edu/service/directory/access/requesting

"The majority of access is based on Kerberos principals. Examples of Kerberos principals are 
service/whatever@stanford.edu, or sunetid@stanford.edu, or webauth/something@stanford.edu."

we prob want https://itservices.stanford.edu/service/directory/bundles/webAuthGeneral bundle, maybe some of the world visible attributes, too.

If we want to assign workgroups for Triannon server to use w webauth: http://web.stanford.edu/dept/as/mais/applications/workgroup/

ndushay commented 9 years ago

@azaroth42 One important question: for webauth'ed request, are we interested in using a string for the person in anno provenance, or a thing? If a thing, how do we get it?

azaroth42 commented 9 years ago

Definitely a thing. But we can use the email address from sunetid as a mailto URI if necessary.

R

On Wed, Apr 15, 2015 at 2:14 PM, Naomi Dushay notifications@github.com wrote:

@azaroth42 https://github.com/azaroth42 One important question: for webauth'ed request, are we interested in using a string for the person in anno provenance, or a thing? If a thing, how do we get it?

— Reply to this email directly or view it on GitHub https://github.com/sul-dlss/triannon/issues/169#issuecomment-93571350.

Rob Sanderson Information Standards Advocate Digital Library Systems and Services Stanford, CA 94305

ndushay commented 9 years ago

world visible: suSunetID, suUniqueIdentifier webAuth bundle: suRegID however they might not always be populated. I have no idea.

ndushay commented 9 years ago

after speaking with @cbeer, the actual directory data the client app utilizes is just sunetid and workgroups. So we need

azaroth42 commented 9 years ago

I think the answer to most of those things is webACLs in Fedora4. But we need to validate the requirements that we should support now.

The easiest thing to do is provenance and populating the annotatedBy agent description, as that's just descriptive with no processing/authorization implications. That seems like a mapping between the webauth accessible properties and foaf (or similar).

On Wed, Apr 15, 2015 at 2:59 PM, Naomi Dushay notifications@github.com wrote:

after speaking with @cbeer https://github.com/cbeer, the actual directory data the client app utilizes is just sunetid and workgroups. So we need

  • spec for how (SW / mirador / xxx) should pass sunetid and workgroup info to triannon in request
  • spec for how to get from sunetid / workgroups to URIs
  • spec for, given a particular sunetid and workgroups, what triannon service actions are allowed
  • spec for, given a particular sunetid and workgroups, what should go in provenance for anno.

— Reply to this email directly or view it on GitHub https://github.com/sul-dlss/triannon/issues/169#issuecomment-93580793.

Rob Sanderson Information Standards Advocate Digital Library Systems and Services Stanford, CA 94305

ndushay commented 9 years ago

connected to #16

ndushay commented 9 years ago

@azaroth42 i think this is dead now? superceded by some other issue/document?

azaroth42 commented 9 years ago

Quite dead :)