© Blackboard, Inc. All rights reserved.

Security and AuthenticationSecurity and Authentication

Tracy EngwirdaPrincipal ConsultantBlackboard Inc.

July 19th

Legal Information…

Any statements in this presentation about future expectations, plans and prospects for the Company, including statements about the Company, the Building Blocks Program 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 various important factors, including: product development, and other factors discussed in our Registration Statement filed on Form S-1 with the SEC.  In addition, the forward-looking statements included in this press release represent the Company’s views as of July 19, 2005. The Company anticipates that subsequent events and developments will cause the Company’s views to change.  However, while the Company may elect to update these forward-looking statements at some point in the future, the Company specifically disclaims any obligation to do so.  These forward-looking statements should not be relied upon as representing the Company’s views as of any date subsequent to July 19, 2005.

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 do 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

» All Part of JDK 1.4» 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 restrictions

» Enforce 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 AccessControlManager

» For 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 walk

» 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

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 S

tack W

alk

Initiates Stack Walk

Terminates Stack Walk

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

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 root

» Read access to data (via APIs)

» Read access to system properties

» Everything 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 permission

» Spawning 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

» Questions?