[Archivesspace_Users_Group] ArchivesSpace RESTful API authentication and access

David P. Steelman dsteelma at umd.edu
Tue Sep 29 12:28:40 EDT 2020


I was able to find the endpoints in the list by searching for
".permissions([])", for example in
archivesspace/backend/app/controllers/agent_family.rb:

  Endpoint.get('/agents/families')
    .description("List all family agents")
    .params()
    .paginated(true)
    .permissions([])
    .returns([200, "[(:agent_family)]"]) \
  do
    handle_listing(AgentFamily, params)
  end

The permissions on this code (and several other classes) were set when the
".nopermissionsyet" scaffolding was replaced about 7 years ago in
https://github.com/archivesspace/archivesspace/commit/ff972d222b91a005f6514ba1d30cd772f8b674c4

So it has been this way for quite a while.

David

On Tue, Sep 29, 2020 at 12:19 PM Joshua D. Shaw <Joshua.D.Shaw at dartmouth.edu>
wrote:

> I think this is an unintended consequence of the PUI.
>
> In
> https://github.com/archivesspace/archivesspace/blob/master/backend/app/model/group.rb
> there is a PUBLIC_GROUP_CODE which is name 'publicanonymous' which is
> granted view_repository rights - presumably so that the PUI can function.
>
> I'm guessing that that specific user should be explicitly *excluded* in
> the RESTHelpers module or maybe the User class where the permissions are
> actually calculated.
>
> Joshua
>
> ------------------------------
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org <
> archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of
> Custer, Mark <mark.custer at yale.edu>
> *Sent:* Tuesday, September 29, 2020 12:15 PM
> *To:* Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] ArchivesSpace RESTful API
> authentication and access
>
> I'm curious if this has always been the case, as well, but it would seem
> like it has been.  I knew that the repository and location endpoints
> could be accessed but didn't try any of the rest for some inexplicable
> reason.  Not good to have agent contact details available that way.
>
> Given which endpoints are available, I wonder if this has to do with the
> concept of the 'global' repository in ArchivesSpace, to which all agents,
> subjects, locations, etc., belong?  If so, it seems like that should be
> something that could (and should!) be locked down.
>
> But, as you mention, Joshua, a very good reason to have further
> restrictions on access to the API endpoints...  but in this case, I
> wouldn't think that should be necessary at all.
>
> ------------------------------
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org <
> archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of
> Joshua D. Shaw <Joshua.D.Shaw at dartmouth.edu>
> *Sent:* Tuesday, September 29, 2020 11:54 AM
> *To:* Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] ArchivesSpace RESTful API
> authentication and access
>
> That's a *very* interesting find! I had naively believed the docs that
> indicated that most of the endpoints required authentication without
> actually trying to bounce off a random endpoint without a token.
>
> The controllers indicate that there should be permissions involved and
> that they should be tied to user roles, but that is obviously not the case.
> FYI - This issue has been around since at least 2.5.0 (I tested against
> 2.5.0, 2.7.1 and 2.80 running locally).
>
> For what it's worth, we have additional firewall rules in place (for other
> reasons) that limit access to the backend to only a select few IPs. That
> doesn't address the actual problem but is a workaround if you have the
> resources.
>
> Joshua
>
> ------------------------------
> *From:* archivesspace_users_group-bounces at lyralists.lyrasis.org <
> archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of
> David P. Steelman <dsteelma at umd.edu>
> *Sent:* Tuesday, September 29, 2020 11:36 AM
> *To:* Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
> *Subject:* [Archivesspace_Users_Group] ArchivesSpace RESTful API
> authentication and access
>
> I've been investigating providing access to the ArchivesSpace RESTful API
> to an expanded group of users.
>
> Through testing, it appears that many of the RESTful API endpoints (see
> below) do not require user authentication (i.e., do not require a "session"
> key), and access apparently cannot be controlled through the ArchivesSpace
> permission infrastructure.
>
> While the information provided by most of these endpoints might be
> considered "public", some (such as information from the "agents" endpoints)
> could contain names and contact information that might be considered
> sensitive.
>
> Is the inability to control access to these endpoints via the
> ArchivesSpace permissions infrastructure intentional? Is there some way to
> control access to these endpoints that I'm missing?
>
> A (non-exhaustive) list of the endpoints that will return information to
> anything that can reach them:
>
> /agents/corporate_entities - List all corporate entity
> /agents/corporate_entities/:id - Get a corporate entity by ID
> /agents/families - List all family agents
> /agents/families/:id - Get a family by ID
> /agents/people - List all person agents
> /agents/people/:id - Get a person by ID
> /agents/software - List all software agents
> /agents/software/:id - Get a software agent by ID
> /container_profiles - Get a list of Container Profiles
> /container_profiles/:id - Get a Container Profile by ID
> /config/enumerations - List all defined enumerations
> /config/enumerations/:enum_id - Get an Enumeration
> /config/enumerations/names/:enum_name - Get an Enumeration by Name
> /config/enumeration_values/:enum_val_id - Get an Enumeration Value
> /repositories/:repo_id/archival_contexts/people/:id.xml - Get an EAC-CPF
> representation of an Agent
> /repositories/:repo_id/archival_contexts/people/:id.:fmt/metadata - Get
> metadata for an EAC-CPF export of a person
> /repositories/:repo_id/archival_contexts/corporate_entities/:id.xml - Get
> an EAC-CPF representation of a Corporate Entity
> /repositories/:repo_id/archival_contexts/corporate_entities/:id.:fmt/metadata
> - Get metadata for an EAC-CPF export of a corporate entity
> /repositories/:repo_id/archival_contexts/families/:id.xml - Get an EAC-CPF
> representation of a Family
> /repositories/:repo_id/archival_contexts/families/:id.:fmt/metadata - Get
> metadata for an EAC-CPF export of a family
> /repositories/:repo_id/archival_contexts/softwares/:id.xml - Get an
> EAC-CPF representation of a Software agent
> /repositories/:repo_id/archival_contexts/softwares/:id.:fmt/metadata - Get
> metadata for an EAC-CPF export of a software
> /job_types - List all supported job types
> /repositories/:repo_id/jobs/import_types - List all supported import job
> types
> /location_profiles - Get a list of Location Profiles
> /location_profiles/:id - Get a Location Profile by ID
> /search/location_profile - Search across Location Profile
> /locations - Get a list of locations
> /locations/:id - Get a Location by ID
> /notifications - Get a stream of notifications
> /oai_config - Get the OAI Config record
> /permissions - Get a list of Permissions
> /repositories/:repo_id/preferences/defaults - Get the default set of
> Preferences for a Repository and optionally a user
> /repositories/:repo_id/rde_templates/:id - Get an RDE template record
> /repositories/:repo_id/rde_templates - Get a list of RDE Templates
> /reports - List all reports
> /repositories/with_agent/:id - Get a Repository by ID, including its agent
> representation
> /repositories/:id - Get a Repository by ID
> /repositories - Get a list of Repositories
> /schemas - Get all ArchivesSpace schemas
> /schemas/:schema - Get an ArchivesSpace schema
> /search/repositories - Search across repositories
> /search/subjects - Search across subjects
> /space_calculator/buildings - Get a Location by ID
> /subjects - Get a list of Subjects
> /subjects/:id - Get a Subject by ID
> /terms - Get a list of Terms matching a prefix
> /users - Get a list of users
> /users/complete - Get a list of system users
> /version - Get the ArchivesSpace application version
> /vocabularies - Get a list of Vocabularies
> /vocabularies/:id/terms - Get a list of Terms for a Vocabulary
> /vocabularies/:id - Get a Vocabulary by ID
>
> Thanks,
>
> David
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20200929/17cae18b/attachment.html>


More information about the Archivesspace_Users_Group mailing list