Enterprise Authorization Grouper/Signet Evaluation

 Proof of Concept Setup and Customizations

• Wrote WebAuth custom authentication filters
• Use AdCom LDAP as subject identity store
• Used Grouper WS and regular Grouper API to load and reload the AdCom FS hierarchy
• Used Grouper+Signet to inherit Group privileges to an individual

 Comparisons to SAMS

• Signet privileges are analogous to SAMS functions
• Signet scope can be used to model SAMS hierarchies (with different subtrees for Payroll, FS, Academic hierarchies, etc)
• You can delegate other users to act as yourself to grant privledges, similar to SAMS DSA (and can be restricted by scope, similar to hierarchy)
• [S] Act as Signet user is similar to SAMS Super DSA
• Limits in Signet are analogous to some hardcoded SAMS restrictions, such as functions requiring training, central office approval and the global requirement of eLogin.  However you can only define what the limits are; the business rules, workflow, and interpretation of limits must be developed outside of Signet (see Cons below).

Pros of Grouper/Signet

• [S] Privileges can be granted to Groups rather than just individuals.
• [S+G] Great data model
• [S+G] Easy to use Java API
• [G] Grouper web service API is adequate
• [S+G] Open source, free
• [S] Can be extended to include resources in the Authz model (i.e. does user X have access to function y over objects 1,2 and 3 within limits a,b,c etc)
• [S] You can delegate administration of subtrees of groups and privileges to different people (however the technical way of doing this is limited, see cons below regarding no GUI)
• [S] An audit trail history is kept for actions of assigning privileges in Signet
• [S] You can model multiple hierarchies/scopes as subtrees in Signet
• [S] They have plugins to provision an LDAP repository with privileges and groups

Cons of Grouper/Signet

• No Signet web service API so far
• Grouper web service API to be released in v1.3.0
• There are no access controls or security in the Grouper web service API (yet)
• The Grouper and Signet APIs are Java based only (until web services are created/finalized)
• The Grouper and Signet APIs require a direct database connection
• There are no access controls within the Grouper/Signet APIs themselves.  For instance as long as your application has access to the API, it can read/update anything
  • Just tested.  I was able to use the API to re-activate a privilege.
• [S+G] No existing pluggable hooks to generate notifications (such as email or more general JMS messages) based on certain actions in the API.  For instance, send an email to the user after a privilege is changed.  Although this is on their roadmap.
• [S] Only way to add new privileges, scope, and groups is through the Java API or XML imports (which must be full imports of the entire schema, not just sections), there is no GUI
• No workflow is integrated in Signet's core, such that you could define privilege X is only granted if approved by Y or a certain requirement (one of the limits) is met.  Instead you can define the limit, however you would have to store how the limit is met or not in an external system, an external workflow system would have to send the request to the entity that fulfills the limit, and the API that resolves whether person X has privilege Y would have to do the querying of the limit fulfillment along with the Signet core itself.  So an example from SAMS would be only grant this privilege to an application if the user has been trained on that application.  An external training database would have to be created that stores trainers, users, and training approval history.  A workflow system would have to route requests for training approval to trainers.  Lastly the Signet API method that determines whether a person is authorized for a certain action would have to recognize the limit on that privilege in Signet as requiring training and know to query the external training database for final authorization.  SAMS supports this, but the workflow is hardcoded for three specific limits, it would be nice if there was a more generalized workflow system and limit datastore which could handle anything, or at least a standard interface.
• [S] There is no nice GUI or canned reports to query audit trail
• [S] No GUI for users to request access on behalf of themselves or others to certain privileges in Signet or groups in Grouper, or even self-subscribe if the privilege/group allows it
• No "MyAccess" or "MyGroups" GUI page that allows a user to view this information of themselves (this would have to be custom page developed for use in staff/student portal), without granting the user access to Signet/Grouper itself.
• [S] No canned or adhoc reports/gui in general to query users, groups, permissions, limits.  These would have to be developed.
• [S] Unable to easily copy access from one user to another, for instance give new employee X everything old employee Y had on date Z.  However this may be an archaic design in SAMS, it may be possible to emulate this by putting common sets of permissions together and grant them to group X, and simply place new employee Y who plays that role in group X and inherit the permissions automatically.
• Auditing is inadequate for most purposes.  Only "grant" actions are logged.  Impossible to determine access at a given point in time.

Questions

• Can a user extend Group inherited privileges?
• How could this integrate with SAML / Shibboleth?
  • Internet2 has a project called COManagethat integrates Signet, Grouper, and Shibboleth
• Are audit logs purely a transaction log, could you easily derive what person X had on date Y?
  • No, only granting is logged.