Blackboard Building Blocks

Framework and Security

Wednesday, April 19, 2023

Tracy Engwirda, Senior Consultant – Asia Pacific

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?

Can the code what it is trying to do?

Topics for Extension Developers

Common Security Tasks– Authentication, Authorization

Declaring Permissions– Often trial and error iteration… add a

permission, get stopped by another one

Overview – Java Security

JSSE – Java Secure Sockets Extension– SSL support, etc.– TLS, RFC-2246

JCE – Java Cryptography Extensions– Pluggable crypto provider framework

Java GSS-API– Java bindings for Generic Security Services API

(RFC-2853)CertPath API

– API for examining certificate chains

Overview – Java Security

JAAS – Java Authentication and Authorization Service– Pluggable Authentication– Authorization for code and principals

Code Security Model– Who can do what– What code can do what

Language Features

Type safety– Compile-time– Run-time

Byte code verification– Well formed class files– No illegal sequences – e.g., check for stack

underflow, etc.

Authentication for Extensions

Simple, let the platform worry about it…

BbSessionManagerService sessionService = BbServiceManager.getSessionManagerService();

BbSession bbSession = sessionService.getSession( request );

AccessManagerService accessManager = (AccessManagerService)BbServiceManager.lookupService( AccessManagerService.class );

if (! bbSession.isAuthenticated() ) { accessManager.sendLoginRedirect(request,response); return;}

Authentication for Extensions

Access Manager coordinates with authentication providers to do the right thing

Default providers– RDBMS– LDAP– Web Server

Custom providers

Authorization in Blackboard

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

SystemRole

Entitlement

CourseRole

User

Membership

1

*

* 1

* 1**

**

Customizing Privileges

It All Comes Back To…

Context!– You have the user, and thus the

system role…– You have the course, and thus the

course role...– Access control works against the full

entitlements mask

Authorization for Extensions

Authorization– Role-based checks – Deprecated...– Entitlement-based checks – Not finalized…

PlugInUtil.authorizeForXXX()– authorizeForCourseControlPanel()– authorizeForSystemAdminPanel()– authorizeForCourse()– authorizeForContent()

Code Security Framework

Leverage security inherent in the Java 2 Standard Edition framework

Enforce certain API restrictionsEnforce API usage disclosure

– Manifest must declare required permissions

Code Security – Historical

“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

Basic Class Hierarchy

+implies()+getName()+getActions()

Permission

BasicPermission

Permissions+add()+implies()+elements()

PermissionCollection

+checkPermission()

SecurityManager

AllPermission

+getProtectionDomain()

Class+getCodeSource()+getPermissions()

ProtectionDomain

+getCertificates()+getPermissions()+implies(in codeSource : CodeSource)

CodeSource checks

1 1

Has

1 1

Has

*0..*

Contains1

1

Has

PersistPermission

+getName()

Principal

0..*

1

Has

Permission Class

Permission– Abstract base class for all permissions– All Permission objects define a name and

actions– Relationships can be created via

implies( Permission )BasicPermission

– Concrete base class for most permissions

Classes

Security information available through Class object– Object.getClass()

ProtectionDomain– Encapsulates information about the classes

physical source and associated permissions– Class.getProtectionDomain()

Classes

PermissionCollection– ProtectionDomain.getPermissions()– List of permissions

• PermissionCollection.implies( Permission )

CodeSource– ProtectionDomain.getCodeSource()– Physical location of class (URL)

• Hierarchical: CodeSource.implies( CodeSource )

– Certificates

Security Checks

SecurityManager.checkPermission( Permission )– Other checkXXX() methods ultimately

delegate to this method– This method, in fact, delegates to

AccessControlManagerFor each frame in call stack

– Get code source– Get permissions for code source– Requested permission implied by permissions

collection?SecurityException thrown if check fails

Checking Permissions

if( _modifyPermission != null ){ System.getSecurityManager()

.checkPermission( _modifyPermission );}

Privileged Blocks

Short-circuit stack walkIf the current frame has permission, allow

accessAllows 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

Examples

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

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; } }

Example

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

Example

ExtensionClass.foo()

AnnouncementDbLoaderImpl.loadById()

NewBaseDbLoader.loadObject()

DbConnectivityPrivilege.run()

Query.executeQuery()

ConnectionManager.getConnection()

SecurityManager.checkPermission()

ExtensionServlet.service()

Ca

ll S

eq

ue

nce

Sta

ck W

alk

Initiates Stack Walk

Terminates Stack Walk

Policies

Policies define the Permissions associated with code bases

Default implementation uses a policy fileGrant/deny permissions to code basesGrant/deny permissions to Subjects

– New in JDK 1.4 with addition of JAAS

Example Policy File Entries

// Tomcat gets all permissionsgrant codeBase "file:${tomcat.home}${/}lib${/}-" { permission java.security.AllPermission;};

grant {

permission java.util.PropertyPermission "java.version", "read"; permission java.util.PropertyPermission "java.vendor", "read";}

Tomcat.policy

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

Blackboard Implementation

wrapper.properties/tomcat.sh– Points to tomcat.policy

service-config.properties– code-level-access-control=true– Can disable SecurityManager regardless of

command line options

Custom Policy implementation

Blackboard Implementation

SecurityUtil.checkPermission()– Hides check for SecurityManager– Propagates Security Exceptions

BbPolicy– Wraps code sources for System Extensions– Attempts to prevent “over-riding”

• You can’t just put permissions in the policy file

Blackboard Permissions

blackboard.persist.PersistPermission– Name is the data object, actions are

“read,create,modify,delete”– Base persister and loader classes check for

permission

Blackboard Permissions

blackboard.data.AttributePermission– Controls access to attributes on a data object– 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

Blackboard Permissions

<permission type=“persist” name=“Content” actions=“create,modify,delete”/>

<permission type=“attribute” name=“user.authinfo” actions=“read,write”/>

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

System Extensions

Enabling an extension at startup– Read permissions from database– Associate with web app code source– Register servlet context with Tomcat

• Registration of servlet context only occurs if extension is “Available” or “Unavailable”. Otherwise, no code may be executed

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, String)

Default Permissions

Read/write access to extension’s home directory

Read access to Blackboard rootRead access to data (via APIs)Read access to system propertiesEverything else must be explicitly

declared…

Example Permissions

<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"/>

</permissions>

Manifest Limitations

No escape syntax– Properties that require user input, or

information from local system, cannot be encoded in permission block

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?

Tips – Common Restrictions

System.getProperties() – returns a mutable copy of the system

permission; thus you need <permission type=“java.util.PropertyPermission”name=“*” actions=“read,write”/>

Reflection requires runtime permissionSpawning a process requires a runtime

permission

Conclusion

System Extensions have access to verify both authentication and authorization

Administrators have an additional level of disclosure about what extensions will access

Thank You

Demos to Follow >