Etrieve Security: What You Need To Know

William Scalf

William Scalf

Security is often seen as a tedious and difficult but necessary part of digital life, and that includes administering enterprise software, but with Etrieve Security we have strived to be the exception. We’ve made it easy to fit Etrieve into your institution by describing a central access control policy instead of managing a handful of disconnected pools of users, and we’ve made it easy for your users to access the software by allowing them to log on with the same credentials they already use at your institution.

Centralized Access Control Policy
In the Doc e Suite, each application maintained its own collection of users and permissions, which required a lot of duplicated setup work at best, but led to confusion and inconsistency due to the lack of a 50,000 foot view. To address this, we’ve adopted a theme of centralization throughout Etrieve Security. Now you can create an institutional policy that manages your users using roles and groups and apply them across the Etrieve product suite.

Users describe the people and services that use Etrieve. Each user can be a member of one or more groups and roles which should describe the access rights necessary for the user to work within the product.

Roles describe specific responsibilities and the permissions necessary to fulfill them. A single role can have permissions in multiple applications and gives you the ability to attach a friendly name to the nuts and bolts underneath, which are useful for job functions that multiple groups of employees share.

For instance, any employee who travels might need to file certain forms or access certain documents in addition to their other job responsibilities. Being a traveling employee would be a responsibility and could be described as a “Traveling Employee” role with the necessary access rights. From then on, if a new permission in any application became necessary for traveling employees, such as a new form to be filed, it could be added to that role in one step and would apply to all traveling employees.

While users can have roles assigned directly to them, it’s best to put users in a group based upon what they do at your institution. A group allows you to define a set of roles and a set of users who perform them, and while they can be arranged any way that makes sense to your institution, they often work best when they represent positions or job titles. This helps keep your authorization policy easy to understand and makes it clear how a new user should be added to the system based on the role they play within your institution. A group eliminates the “make this user just like that one” headache that’s so common when onboarding new employees. It also makes it easy to understand when to add or remove roles; those changes would be driven by changes to the responsibilities of a position or job title.

Here’s an example of why keeping your users in groups is so powerful. Consider the “Traveling Employees” role from the Roles section. If a position changed to include travel the “Traveling Employees” role could easily be added to that position’s group and all of the users within it would have the necessary permissions that go along with travel.

If your institution uses Microsoft Active Directory (AD), groups take on another level of flexibility. They can be connected to authorization groups within AD, which allows you to map your institution’s authorization policy directly from your domain into Etrieve. If you have granular AD groups and a group/role structure within Etrieve that roughly matches it, onboarding new users is as easy as adding them to the appropriate AD groups and letting Etrieve take it from there.

Understand your institution’s access policy at a glance
There should never be any mystery as to who has access to what is in an enterprise software solution. With Etrieve Security, we’ve not only made granting very granular permissions simple, we’ve built in some analysis features to make it transparent.

At any time, you can view any user’s effective permissions, including any permissions inherited from Microsoft AD group membership. You can also view the effective permissions of a group or role, which helps you stay on top of what your access policy is and helps you understand the potential impact of any changes you intend to make.

Use existing accounts
Etrieve takes things to the next level with authentication store integration. We offer integration with a variety of identity solutions so that your users can continue to use the accounts they use every day when accessing Etrieve. This means they have fewer passwords to remember and can use a familiar login workflow without having to learn something new. And for providers that offer single sign-on, accessing Etrieve isn’t even an additional login – the existing session allows access without re-authentication.

Microsoft Active Directory
Active Directory is where Etrieve has its tightest integration. Not only can you log on with your AD credentials, but as mentioned above in the Groups section, you can use your institution’s AD authorization groups to associate users with Etrieve Security groups, meaning there may not be any work in Etrieve Security when adding new users.

Windows Live
Does your institution use Live@Edu or Windows Live accounts? Etrieve fully supports using your Live account through Windows Live’s login workflow, which includes support for two-step verification using your smartphone or other device.

Does your institution use Google Apps for Business or Google Apps for Education? You can sign in using your Google account as well. And like Windows Live authentication, Google authentication uses Google’s login workflow, so Google-specific features such as verification codes and physical security keys are fully supported. It is like it’s just another Google App in your workflow.

Need to provide access to users that don’t have accounts on your network such as parents? Facebook authentication provides a great option, especially for processes such as student enrollment or financial aid verification.

Federated Identity Providers
We implement the WS-Federation standard, which allows us to integrate with a number of other identity providers that follow it, like Active Directory Federation Services (ADFS), CAS and Shibboleth. If your provider of choice supports it and isn’t on this list, let us know!

Etrieve Accounts
Standalone Etrieve accounts allow people who aren’t in any of your identity providers to access the system. These are analogous to ‘Database’ accounts in Doc e Fill and are the only account type where Etrieve stores any credentials. The passwords for these accounts are protected with strong PBKDF2 hashing, described in another blog here.

Are your needs a little more varied? Etrieve has you covered! Maybe you need to manage employees in Active Directory while students are in Live@Edu and hourly employees need Etrieve accounts. Maybe your scenario is even more complicated.

In any case, Etrieve Security can manage user accounts from any of these sources and more for a single institution. When a user first attempts to log in, they are prompted for which of your institution’s identity providers they would like to use, and the identity provider’s workflow picks up from there. If they like, their selection can be saved so they do not have to be prompted again.

It’s that easy.

A streamlined experience for everyone involved.
Where security is often seen a source of friction, Etrieve Security makes things smooth between your institution, your Etrieve installation and the people who use it. Administrators have a variety of tools with which to describe how the job functions within their institution should behave in Etrieve, and users log on to do those jobs using the familiar login workflows they use every day.

How will Etrieve Security fit into your institution?