[Archivesspace_Users_Group] More admins, more problems

[Jason Loeffler]

Residing at "very small" ArchivesSpace membership level, we don't have a
lot of surplus developer time. But I desperately welcome a general
discussion of how security is handled at the application level, how the
plugin architecture works with regard to authentication, and how to begin
scoping our own SSO/SAML project. Meantime, I'm restricting access at the
firewall....pretty coarse for sure.

Some discussion in the source here
<https://github.com/archivesspace/archivesspace/blob/4c26d82b1b0e343b7e1aea86a11913dcf6ff5b6f/backend/Authentication.md>.
And there's the Dartmouth CAS plugin which looks like solid work.

Lastly from the 2010 Technical Architecture Report, probably superseded by
another document....

*During the technical planning meeting, nearly all attendees agreed that
both a local authentication mechanism, backed by data stored in the
persistence layer, was a key baseline requirement for the merged
application. Additionally, attendees clearly stated that the application
needs an abstracted, pluggable authentication layer that allows for
implementers to use a particular authentication system supported by their
institution. With this in mind, much of the discussion did not focus on
providing a detailed evaluation of particular authentication mechanisms.
However, attendees recommended potential support for a number of
authentication systems, such as the Central Authentication Service (CAS),
LDAP, Pubcookie, Shibboleth, WebAuth, and OpenID. Attendees representing
the perspective of information technology managers ranked IP address-based
authentication as an extremely low priority. Use of a pluggable
authentication mechanism would also allow implementers to create additional
modules that authenticate against other single sign-on systems not
supported in the merged application's initial development phases, such as
institution-specific systems.*

JL

Jason Loeffler
Technology Consultant
The American Academy in Rome
Minor Science | Application Development & Metadata Strategy
Brooklyn, New York

On Tue, Feb 9, 2016 at 4:08 PM, Prom, Christopher John <prom at illinois.edu>
wrote:

> Mark,
>
> Thanks for bringing this up.
>
> I just checked and in the case of the archon migrations, the asadmin user
> is not created.  However, it does make a user ‘aspace’ and grants it full
> admin rights.  Even worse, you can login as that user with NO password
> (i.e. field is blank).  So, that one should definitely be killed off
> manually or even better the migration tool should delete it when done.
>
> In addition, there is another problem with archon migrations, in that the
> migration tool takes ALL of the existing users from archon DBs, and
> migrates them into aspace as read only users with the same login, and no
> password.   You can then login to the app with the old users name and no
> password (field is blank) and can view but not edit data.
>
> All of the users the migration tool create are read only—but still this is
> a security problem since someone might be able to view restricted data or
> find a hack to get more permissions on the DB.
>
> As a related question, how is security handled generally in ASpace?  Is it
> relying on an external security library, or bespoke code, or some
> combination of the two?
>
> The discovery of these types of things, in all honesty, does not engender
> confidence, and probably indicates the need for a thorough security audit.
> While the above problems can be cleaned up after the fact, not an ideal
> solution.
>
> Chris Prom
> Univeristy of Illinois Archives
>
> On Feb 9, 2016, at 2:39 PM, Custer, Mark <mark.custer at yale.edu> wrote:
>
> All,
>
>
>
> I wanted to send out a friendly reminder about admin accounts in
> ArchivesSpace (and this is coming strictly from an ArchivesSpace user’s
> perspective).
>
>
>
> As most are aware, when you install ArchivesSpace without any
> configuration changes, you wind up with a single admin account in
> ArchivesSpace that has a username equal to “*admin*” and a password set
> to be the same.  You’ll want to change this password to something else long
> before you go into production mode.  For the most part, I think that people
> take care of this on or around day one, but if you can log into your ASpace
> application using that username and password, you’ll want to update that
> password to something else that’s a lot more secure!
>
>
>
> Less well known is what happens when you use the migration tool to
> populate your ArchivesSpace database (I sent an email about this to the
> listserv way back on May 8, 2015, but I don’t know if what I’m about to
> describe is documented anywhere else yet).  If you’ve migrated to
> ArchivesSpace using the Archivists’ Toolkit migration tool (and I’m pretty
> sure this happens with the Archon tool, as well), then another admin user
> will be added to your database.  This admin user will have a username
> that’s equal to “*asadmin*”.  I’m not actually sure why the migration
> tool creates another user (or if the current versions still do this),
> especially since you have to supply admin credentials to the migration tool
> to run against the ASpace API, but I know that this happened during our
> migration process – and I’ve seen this phantom admin user account in other
> ArchivesSpace installations, as well.  When we discovered this new user, we
> deleted it from our database immediately after our final migration process.
>
>
>
> So, I’d like to ask everyone out there to check and see if they can login
> to their own ArchivesSpace with an “*asadmin*” account, whether you’re in
> production or not (the password is easy to guess, since it’s the same as
> the default admin user’s password).  If you can log in that way, I’d
> suggest deleting that user immediately!
>
>
>
> Mark
>
>
>
>
>
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
>
> _______________________________________________
> 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/20160209/05e25522/attachment.html>