Re: [Archivesspace_Users_Group] ArchivesSpace RESTful API authentication and access
And as a follow-follow-up Christine has moved this to a private JIRA since it
impacts security,
jds
From: archivesspace_users_group-boun...@lyralists.lyrasis.org
on behalf of Joshua
D. Shaw
Sent: Monday, October 5, 2020 1:58 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] ArchivesSpace RESTful API
authentication and access
Just as a follow-up, I've created a JIRA ticket about this:
https://archivesspace.atlassian.net/browse/ANW-1123<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchivesspace.atlassian.net%2Fbrowse%2FANW-1123=02%7C01%7Cjoshua.d.shaw%40dartmouth.edu%7Cb6400c9b51344848a19f08d869584a2f%7C995b093648d640e5a31ebf689ec9446f%7C0%7C1%7C637375175218837925=hFQXYFn10knzaxY7vVpUaGQBIN5i6X8rsewbC65QUiw%3D=0>
jds
From: archivesspace_users_group-boun...@lyralists.lyrasis.org
on behalf of Joshua
D. Shaw
Sent: Tuesday, September 29, 2020 12:39 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] ArchivesSpace RESTful API
authentication and access
David is totally correct. Not related to the public user at all as I had
initially speculated.
I wonder why some of the get endpoints never got specific permissions? At a
minimum I think they should all be 'view_repository' but that might have some
other consequences downstream.
Joshua
From: archivesspace_users_group-boun...@lyralists.lyrasis.org
on behalf of David P.
Steelman
Sent: Tuesday, September 29, 2020 12:28 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] ArchivesSpace RESTful API
authentication and access
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<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Farchivesspace%2Farchivesspace%2Fcommit%2Fff972d222b91a005f6514ba1d30cd772f8b674c4=02%7C01%7Cjoshua.d.shaw%40dartmouth.edu%7Cb6400c9b51344848a19f08d869584a2f%7C995b093648d640e5a31ebf689ec9446f%7C0%7C1%7C637375175218837925=G%2FpBs7IWL8QCojtYz5cd9JKCh%2FbFTrA7xxK%2BomQdvqg%3D=0>
So it has been this way for quite a while.
David
On Tue, Sep 29, 2020 at 12:19 PM Joshua D. Shaw
mailto:joshua.d.s...@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<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Farchivesspace%2Farchivesspace%2Fblob%2Fmaster%2Fbackend%2Fapp%2Fmodel%2Fgroup.rb=02%7C01%7Cjoshua.d.shaw%40dartmouth.edu%7Cb6400c9b51344848a19f08d869584a2f%7C995b093648d640e5a31ebf689ec9446f%7C0%7C1%7C637375175218847917=B1IQua%2Bo4pecFJ%2BBf9EGVxluZamf4D0pCkUgALj2AGY%3D=0>
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-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
on behalf of Custer, Mark mailto:mark.cus...@yale.edu>>
Sent: Tuesday, September 29, 2020 12:15 PM
To: Archivesspace Users Group
mailto:archivesspace_users_group@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.
___
Re: [Archivesspace_Users_Group] ArchivesSpace RESTful API authentication and access
Just as a follow-up, I've created a JIRA ticket about this:
https://archivesspace.atlassian.net/browse/ANW-1123
jds
From: archivesspace_users_group-boun...@lyralists.lyrasis.org
on behalf of Joshua
D. Shaw
Sent: Tuesday, September 29, 2020 12:39 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] ArchivesSpace RESTful API
authentication and access
David is totally correct. Not related to the public user at all as I had
initially speculated.
I wonder why some of the get endpoints never got specific permissions? At a
minimum I think they should all be 'view_repository' but that might have some
other consequences downstream.
Joshua
From: archivesspace_users_group-boun...@lyralists.lyrasis.org
on behalf of David P.
Steelman
Sent: Tuesday, September 29, 2020 12:28 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] ArchivesSpace RESTful API
authentication and access
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<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Farchivesspace%2Farchivesspace%2Fcommit%2Fff972d222b91a005f6514ba1d30cd772f8b674c4=02%7C01%7Cjoshua.d.shaw%40dartmouth.edu%7C15011e62629045369b7c08d864964baa%7C995b093648d640e5a31ebf689ec9446f%7C0%7C1%7C637369943981304095=XnmHE5BT%2BgkMm5pyw9O0KDtASrYArkiEwiYcc8Eq%2BQs%3D=0>
So it has been this way for quite a while.
David
On Tue, Sep 29, 2020 at 12:19 PM Joshua D. Shaw
mailto:joshua.d.s...@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<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Farchivesspace%2Farchivesspace%2Fblob%2Fmaster%2Fbackend%2Fapp%2Fmodel%2Fgroup.rb=02%7C01%7Cjoshua.d.shaw%40dartmouth.edu%7C15011e62629045369b7c08d864964baa%7C995b093648d640e5a31ebf689ec9446f%7C0%7C1%7C637369943981314058=J22%2F1vJpIfIl9QGPi3F1QAYN0sjkjzQcHmQm6B7A2Ic%3D=0>
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-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
on behalf of Custer, Mark mailto:mark.cus...@yale.edu>>
Sent: Tuesday, September 29, 2020 12:15 PM
To: Archivesspace Users Group
mailto:archivesspace_users_group@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-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
on behalf of Joshua D. Shaw
mailto:joshua.d.s...@dartmouth.edu>>
Sent: Tuesday, September 29, 2020 11:54 AM
To: Archivesspace Users Group
mailto:archivesspace_users_group@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
Re: [Archivesspace_Users_Group] ArchivesSpace RESTful API authentication and access
David is totally correct. Not related to the public user at all as I had
initially speculated.
I wonder why some of the get endpoints never got specific permissions? At a
minimum I think they should all be 'view_repository' but that might have some
other consequences downstream.
Joshua
From: archivesspace_users_group-boun...@lyralists.lyrasis.org
on behalf of David P.
Steelman
Sent: Tuesday, September 29, 2020 12:28 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] ArchivesSpace RESTful API
authentication and access
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<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Farchivesspace%2Farchivesspace%2Fcommit%2Fff972d222b91a005f6514ba1d30cd772f8b674c4=02%7C01%7Cjoshua.d.shaw%40dartmouth.edu%7C4d54a77c5b5f4b7eb15e08d86494c298%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637369937387429327=u2y8VNCm0cCJAO5VGL6g0MH6NxFID5yF01G6vVRX0Hk%3D=0>
So it has been this way for quite a while.
David
On Tue, Sep 29, 2020 at 12:19 PM Joshua D. Shaw
mailto:joshua.d.s...@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<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Farchivesspace%2Farchivesspace%2Fblob%2Fmaster%2Fbackend%2Fapp%2Fmodel%2Fgroup.rb=02%7C01%7Cjoshua.d.shaw%40dartmouth.edu%7C4d54a77c5b5f4b7eb15e08d86494c298%7C995b093648d640e5a31ebf689ec9446f%7C0%7C0%7C637369937387429327=duyanMKYMzsbj7KesfEkIEmpK%2F9xfGI2V0Kj6x0ehsA%3D=0>
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-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
on behalf of Custer, Mark mailto:mark.cus...@yale.edu>>
Sent: Tuesday, September 29, 2020 12:15 PM
To: Archivesspace Users Group
mailto:archivesspace_users_group@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-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
on behalf of Joshua D. Shaw
mailto:joshua.d.s...@dartmouth.edu>>
Sent: Tuesday, September 29, 2020 11:54 AM
To: Archivesspace Users Group
mailto:archivesspace_users_group@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
Re: [Archivesspace_Users_Group] ArchivesSpace RESTful API authentication and access
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
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-boun...@lyralists.lyrasis.org <
> archivesspace_users_group-boun...@lyralists.lyrasis.org> on behalf of
> Custer, Mark
> *Sent:* Tuesday, September 29, 2020 12:15 PM
> *To:* Archivesspace Users Group <
> archivesspace_users_group@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-boun...@lyralists.lyrasis.org <
> archivesspace_users_group-boun...@lyralists.lyrasis.org> on behalf of
> Joshua D. Shaw
> *Sent:* Tuesday, September 29, 2020 11:54 AM
> *To:* Archivesspace Users Group <
> archivesspace_users_group@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-boun...@lyralists.lyrasis.org <
> archivesspace_users_group-boun...@lyralists.lyrasis.org> on behalf of
> David P. Steelman
> *Sent:* Tuesday, September 29, 2020 11:36 AM
> *To:* Archivesspace Users Group <
> archivesspace_users_group@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
Re: [Archivesspace_Users_Group] ArchivesSpace RESTful API authentication and access
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-boun...@lyralists.lyrasis.org on behalf of Custer, Mark Sent: Tuesday, September 29, 2020 12:15 PM To: Archivesspace Users Group 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-boun...@lyralists.lyrasis.org on behalf of Joshua D. Shaw Sent: Tuesday, September 29, 2020 11:54 AM To: Archivesspace Users Group 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-boun...@lyralists.lyrasis.org on behalf of David P. Steelman Sent: Tuesday, September 29, 2020 11:36 AM To: Archivesspace Users Group 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-C
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-boun...@lyralists.lyrasis.org on behalf of Joshua D. Shaw Sent: Tuesday, September 29, 2020 11:54 AM To: Archivesspace Users Group 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-boun...@lyralists.lyrasis.org on behalf of David P. Steelman Sent: Tuesday, September 29, 2020 11:36 AM To: Archivesspace Users Group 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 -
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-boun...@lyralists.lyrasis.org on behalf of David P. Steelman Sent: Tuesday, September 29, 2020 11:36 AM To: Archivesspace Users Group 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 applicati
[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@lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
