1. © Blackboard, Inc. All rights reserved. Security and Authentication with Blackboard Building Blocks™ David Ashman Senior Software Architect, Product Development Blackboard Inc.

2. 2 About Forward Looking Statements Any statements in this presentation about future expectations, plans and prospects for Blackboard and other statements containing the words “believes,” “anticipates,” “plans,” “expects,” “will,” and similar expressions, constitute forward-looking statements within the meaning of The Private Securities Litigation Reform Act of 1995. Actual results may differ materially from those indicated by such forward-looking statements as a result of product development changes and other important factors discussed in our filings with the SEC. We may make statements regarding our product development and service offering initiatives, including the content of future product upgrades, updates or functionality in development. While such statements represent our current intentions, they may be modified, delayed or abandoned without prior notice and there is no assurance that such offering, upgrades, updates or functionality will become available unless and until they have been made generally available to our customers.

3. 3 Security – High Level View » Authentication » Who is using the system? » Authorization » Can that user do what they’re trying to do? » Privacy » Is the users’ data kept private? » Integrity » Has the data been tampered with?

4. 4 Topics for Extension Developers » Common Security Tasks » Authentication, Authorization » Declaring Permissions » Often trial and error iteration… add a permission, get stopped by another one

5. © Blackboard, Inc. All rights reserved. Authentication

6. 6 Authentication for Extensions » Simple, let the platform worry about it… » AccessManager coordinates with authentication providers to do the right thing BbSessionManagerService sessionService = BbServiceManager.getSessionManagerService(); // get the current session to check authentication status BbSession bbSession = sessionService.getSession( request ); if ( !bbSession.isAuthenticated() ) { // redirect to the login page AccessManagerService accessManager = (AccessManagerService)BbServiceManager.lookupService( AccessManagerService.class ); accessManager.sendLoginRedirect(request,response); return; }

7. 7 Default Authentication Providers » RDBMS » Uses USERS table from Blackboard application schema » LDAP » Supports standard JNDI based authentication against LDAP » Webserver » Uses REMOTE_USER environment variable set by server authentication mechanisms

8. 8 Custom Authentication Providers » blackboard.platform.security.authentication.HttpAuthModule » Interface that defines the authentication contract » Can implement integration with any third-party authentication system » blackboard.platform.security.authentication.BaseAuthenticationModule » Default implementation » RDBMS-based » blackboard.platform.security.authentication.LDAPAuthModule » Default LDAP authenticator

9. 9 Custom Authentication Providers » authentication.properties » Stores configuration about authentication providers » Which type is driven by bbconfig.auth.type property in bb-config.properties

10. © Blackboard, Inc. All rights reserved. Authorization

11. 11 Authorization in Blackboard Systems » Role-based assignment » System role attached to user object » Course role attached to enrollment record » Privileges attached to Roles » Editable » Check relies on the union of all relevant entitlements

12. 12 Entitlements » New security model based on entitlements » Each role has a set of entitlements » Always additive, no way to revoke entitlements » Authorization is based on a user having an entitlement in one of their roles

13. 13 Flexible Roles » New system roles can be created after installation » Privileges for system and course roles can be customized after installation

14. 14 It All Comes Back To… » Context! » With the User, you know the System role » With the Course, you know the Course role » The entitlements in each add up to the user’s full privileges

15. 15 Authorization for Extensions » PlugInUtil.authorizeForXXX() » Provides shortcut for authorization checks for typical actions » authorizeForSystemAdmin () » authorizeForCourse() » authorizeForCourseControlPanel() » authorizeForCourseControlPanelContent()

16. © Blackboard, Inc. All rights reserved. Code-level Security

17. 17 Code Security Framework » Leverage security inherent in the Java 2 Standard Edition framework » Enforce certain API restrictions » Enforce API usage disclosure » Manifest must declare required permissions

18. 18 Code Security History » “Sandbox” model – JDK 1.0 » Applets just couldn’t do certain things » Hard to manage/understand » “Trusted” model – JDK 1.1 » Permissions assignable to trusted code » Code (applets) could be signed » “Domain” model – JDK 1.2 » Policy » Domains

19. 19 Basic Class Hierarchy

20. 20 Code Security Classes » Permission » Abstract base class for all permissions » All Permission objects define a name and actions » Relationships can be created via implies( Permission )

21. 21 Code Security Classes » ProtectionDomain » Encapsulates information about the classes physical source and associated permissions » Class.getProtectionDomain()

22. 22 Code Security Classes » CodeSource » ProtectionDomain.getCodeSource() » Physical location of class (URL) » Hierarchical: CodeSource.implies( CodeSource ) » Certificates

23. 23 Security Checks » SecurityManager.checkPermission( Permission ) » Other checkXXX() methods ultimately delegate to this method » This method, in fact, delegates to AccessControlManager » For each frame in call stack » Get code source » Get permissions for code source » Requested permission implied by permissions collection?

24. 24 Checking Permissions if( _modifyPermission != null ) { System.getSecurityManager().checkPermission( _modifyPermission ); }

25. 25 Privileged Blocks » If the current frame has permission, allow access » Allows trusted code to perform actions that may not be granted to the caller » E.g., un-trusted code may not have network permission, but the database driver does

26. 26 Example » We do not allow System Extensions to get raw database connections » Our own code, which may be called by a System Extension, needs to get a database connection » Solution: Privileged block » Code executing with more privileges can accomplish what it needs to

27. 27 Example private class DbConnectivityPrivilege implements PrivilegedExceptionAction { private Query _query; private Connection _con; private DbConnectivityPrivilege(Query query, Connection con) { _query = query; _con = con; } public Object run() throws Exception { _query.executeQuery( _con ); return null; }

28. 28 Example try { AccessController.doPrivileged( new DbConnectivityPrivilege(query, con)); } catch(PrivilegedActionException pae) { castException( pae ); }

29. 29 Example Initiates Stack Walk Terminates Stack Walk

30. 30 Policies » Policies define the Permissions associated with code bases » Default implementation uses a policy file » Grant/deny permissions to code bases » Grant/deny permissions to Subjects » Person or Service » New in JDK 1.4 with addition of JAAS

31. 31 Example Policy File Entries // Tomcat gets all permissions grant codeBase "file:${tomcat.home}${/}lib${/}-" { permission java.security.AllPermission; }; grant { permission java.util.PropertyPermission "java.version", "read"; permission java.util.PropertyPermission "java.vendor", "read"; }

32. 32 Activating Security » Run-time properties on the command line » -Djava.security.manager » -Djava.security.policy » java.security » Configuration file for setting security providers » policy.provider » Class that is responsible for implementing the policy » Default is sun.security.provider.PolicyFile

33. 33 Blackboard Implementation » service-config.properties » code-level-access-control=true » Can disable SecurityManager regardless of command line options » BbPolicy » Custom Policy implementation to support extensions » Wraps code sources for system extensions » Attempts to prevent “over-riding” » You can’t just put permissions in the policy file » SecurityUtil.checkPermission() » Hides call to SecurityManager » Propagates Security Exceptions

34. 34 System Extensions » Deployed as a web application with a unique code source » Code source is attached to /plugin directory, so it encompasses the /webapp and /config directories » Manifest includes a permissions block » Some filtering to restrict certain permissions » Manifest is equivalent of policy file

35. 35 System Extensions » Permissions block contains 0 or more permission elements » Same semantics as “grant” entries in the standard Java policy file » No explicit deny » Simple mnemonics for common types » Runtime, Socket, Persist, Attribute » Type attribute can be any fully qualified Java classname » Must be a Permission sub-class, with two argument constructor (String name, String actions)

36. 36 Example Permissions <permission type=“socket” name=“api.google.com” actions=“connect”/> <permission type=“runtime” name=“accessDeclaredMembers” actions=“”/> <permission type="java.util.PropertyPermission“ name="java.protocol.handler.pkgs" actions="write"/>

37. 37 Default Permissions » Read/write access to extension’s home directory » Read access to Blackboard root » Read access to data (via APIs) » Read access to system properties » Everything else must be explicitly declared…

38. 38 Blackboard Custom Permissions » blackboard.persist.PersistPermission » Limits permitted actions on loaders and persisters » blackboard.data.AttributePermission » Controls access to attributes on a data object

39. 39 Blackboard Custom Permissions » blackboard.persist.PersistPermission » Name is the data object, actions are “read,create,modify,delete” » Base persister and loader classes check for permission

40. 40 Blackboard Custom Permissions » blackboard.data.AttributePermission » Naming convention allows single attributes or groups to be protected » E.g., untrusted code can load a user, but can’t get the (hashed) password

41. 41 Blackboard Permissions

42. 42 Tips » Read the Javadoc for any third party libraries you are using » Many developers don’t test their code with a security manager, so they don’t know what they’re touching » E.g., Axis configuration routines will throw SecurityException if run with a SecurityManager » Think security… » What would you as an administrator want to see disclosed?

43. 43 Tips – Common Restrictions » System.getProperties() » returns a mutable copy of the system permission; thus you need: » Reflection requires runtime permission » Spawning a process requires a runtime permission

44. 44 Conclusion » System Extensions have access to verify both authentication and authorization » Administrators have an additional level of disclosure about what extensions will access

45. © Blackboard, Inc. All rights reserved. Questions?