Wednesday, February 15, 2012

SuperUser Building Blocks

Note: Review was done in March 2011.

Sakai had the super-user ability where admins could become another person. Typically they use this to investigate student issues (to see what they see).

There are at least two community-developed building blocks that would give similar functionality in Blackboard:


Impersonate (v1.0.12)
  • More restrictive permissions. Impersonate can only be done by Systems Administrators, not just anyone with access to the system administration page.
  • Permissions are now appropriate to the needs of the block.
  • Taglibs consistently use bbNG.
  • Simple logging of impersonation to Tomcat stdout.

My Findings:
  • shows up in Admin tab >  Tools and Utilities
  • restricted to System Administrators, so can't be easily given out 
LoginAs (v2.0.0 - to work with 9.1SP4 or later):

This building block allows the administrator to create a valid session as a different user. For the purpose of validating portal customizations or troubleshooting administrators often use multiple accounts to access the system. This method allows the preserve the original password. Access can be granted by Institutional Role, System Role, or Course Membership. It is a parallel to the Unix su command. It effectively allows to impersonate another user. Logging in as system administrators can disallowed in settings.

My Findings:

  • Shows up in under the Admin tab > Tools and Utilities
  • Can be restricted to an Institutional Role (e.g., I created a Institutional Role called DOMAIN_LOGINAS) also says you can use system roles: System Administrator, System Support, Account Administrator
Note: did not seem to pick up domain admin roles, e.g., if I assigned the Institutional Role DOMAIN_LOGINAS to a domain admin, the building block did not pick it up.

  • Can additionally be restricted by Course ID (e.g., membership in a particular course)
In addition to using Roles you can use course membership. Enroll users in a specific course as students and provide Course ID here. Also works for Orgs (if you have Community).

If users do not have access to the Admin tab, but should have access to LoginAs simply provide access to this url in a course or organization: The LoginAs direct URL

Note: In conversation with Syzmon (developer), he recommended using the course membership over the role.  His intention is to simplify the access to courses only in the future (this way basic license clients are covered).  The option will continue to prohibit login as an administrator type account.

  • Disallow LoginAs to a System Adminitrator level user (NOTE: DEFAULT IS NO, WHICH MEANS YOU CAN BECOME ADMINISTRATOR)
You can use the Yes string to prevent users from possible privilege escalation activity.
Recommend setting it to Yes. Then if you try to become Administrator, you get "Request denied. Authentication requested for System Administrator: administrator"

  • Simple logging to Tomcat logs. It makes it difficult to then easily find out who logged in as whom.

bb-access.log would show entries like:

123.456.789.10 - _2_1 [05/Aug/2011:10:30:50 -0400] "GET 
/webapps/grcc-LoginAs-bb_bb60/index.jsp?username=user2&OriginatingUser=user1
 HTTP/1.1" 200 19571 

2 comments:

  1. ps. Johns Hopkins has contributed code back to LoginAs for logging and viewing login changes. http://projects.oscelot.org/gf/project/loginas/frs/?action=FrsReleaseView&release_id=641

    ReplyDelete