<div dir="ltr"><div>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.<br></div><div><br></div>Some discussion in the source <a href="https://github.com/archivesspace/archivesspace/blob/4c26d82b1b0e343b7e1aea86a11913dcf6ff5b6f/backend/Authentication.md" target="_blank">here</a>. And there's the Dartmouth CAS plugin which looks like solid work. <div><br></div><div>Lastly from the 2010 Technical Architecture Report, probably superseded by another document....<div><br></div><div><i>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.</i><br><div><br></div><div><div class="gmail_extra">JL</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div><div style="font-size:12.8px"><div><font size="2" face="garamond, serif" color="#666666">Jason Loeffler</font></div><div><font color="#666666" face="garamond, serif">Technology Consultant</font></div><div><font color="#666666" face="garamond, serif">The American Academy in Rome</font></div><div><font size="2" face="garamond, serif" color="#666666">Minor Science | Application Development & Metadata Strategy</font></div><div><font size="2" face="garamond, serif" color="#666666">Brooklyn, New York</font></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Feb 9, 2016 at 4:08 PM, Prom, Christopher John <span dir="ltr"><<a href="mailto:prom@illinois.edu" target="_blank">prom@illinois.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">
Mark,
<div><br>
</div>
<div>Thanks for bringing this up. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>
<div>
<div>
<div>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? </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Chris Prom</div>
<div>Univeristy of Illinois Archives</div>
<div><br>
<blockquote type="cite">
<div>On Feb 9, 2016, at 2:39 PM, Custer, Mark <<a href="mailto:mark.custer@yale.edu" target="_blank">mark.custer@yale.edu</a>> wrote:</div>
<br>
<div>
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">All,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">I wanted to send out a friendly reminder about admin accounts in ArchivesSpace (and this is coming strictly from an ArchivesSpace user’s perspective).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">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 “<b>admin</b>” 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!<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">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 “<b>asadmin</b>”. 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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">So, I’d like to ask everyone out there to check and see if they can login to their own ArchivesSpace with an “<b>asadmin</b>” 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!<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Mark<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
</div>
</div>
_______________________________________________<br>
Archivesspace_Users_Group mailing list<br>
<a href="mailto:Archivesspace_Users_Group@lyralists.lyrasis.org" target="_blank">Archivesspace_Users_Group@lyralists.lyrasis.org</a><br>
<a href="http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group" target="_blank">http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
<br>_______________________________________________<br>
Archivesspace_Users_Group mailing list<br>
<a href="mailto:Archivesspace_Users_Group@lyralists.lyrasis.org" target="_blank">Archivesspace_Users_Group@lyralists.lyrasis.org</a><br>
<a href="http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group" rel="noreferrer" target="_blank">http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group</a><br>
<br></blockquote></div><br></div></div></div></div></div>