Transcript C&P SERVICES STRATEGY

Security and
Authentication
Tracy Engwirda
Principal Consultant
Blackboard Inc.
July 19th
© Blackboard, Inc. All rights reserved.
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 forwardlooking 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
the
code
dothey’re
whattrying
it istotrying
to
Can that
user
do what
do?
do?
Privacy
»
»
»
Is the users’ data kept private?
Integrity
»
Has the data been tampered with?
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
»
»
»
JCE – Java Cryptography Extensions
»
»
Pluggable crypto provider framework
Java GSS-API
»
»
SSL support, etc.
TLS, RFC-2246
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
User
»
SystemRole
* 1
1
Entitlement
**
*
»
Privileges attached to
Roles
Editable
» Check relies on the union of all
relevant entitlements
»
*
*
Membership
CourseRole
* 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
»
»
»
“Trusted” model – JDK 1.1
»
»
»
Applets just couldn’t do certain things
Hard to manage/understand
Permissions assignable to trusted code
Code (applets) could be signed
“Domain” model – JDK 1.2
»
»
Policy
Domains
Basic Class Hierarchy
Principal
+getName()
0..* Has
1
Has
Class
+getProtectionDomain()
1
1
+getCodeSource()
+getPermissions()
1
PermissionCollection
Has
ProtectionDomain
1
1
Permissions
+add()
+implies()
+elements()
Has
Contains
*
0..*
1
CodeSource
Permission
+getCertificates()
+getPermissions()
+implies(in codeSource : CodeSource)
+implies()
+getName()
+getActions()
AllPermission
checks
SecurityManager
+checkPermission()
BasicPermission
PersistPermission
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 )
»
»
»
For each frame in call stack
»
»
»
»
Other checkXXX() methods ultimately
delegate to this method
This method, in fact, delegates to AccessControlManager
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
Initiates Stack Walk
SecurityManager.checkPermission()
Query.executeQuery()
DbConnectivityPrivilege.run()
NewBaseDbLoader.loadObject()
AnnouncementDbLoaderImpl.loadById()
ExtensionClass.foo()
ExtensionServlet.service()
Terminates Stack Walk
Stack Walk
Call Sequence
ConnectionManager.getConnection()
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.policy
// 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";
}
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
»
»
service-config.properties
»
»
»
Points to tomcat.policy
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
»
»
Simple mnemonics for common types
»
»
No explicit deny
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?