Security Architecture of the Java Platform
summary
Chronicles the Java platform’s security from 1.0 applet sandbox to modular Jigsaw: signed applets grant system-level privileges if certificates are trusted; 1.2 adds security manager and ProtectionDomain so permissions come from codebase and policy files; the JVM enforces the intersection of protection domains across classloaders; JAAS adds principal-based grants; JCA/JSSE/GSS/SASL provide crypto and auth plumbing; use doPrivileged sparingly; real-world: Google’s JSON library needed code changes to run in OSGi under a restrictive policy.
AI-written summary · about
chapters (17)
- 0:00Start
- 0:52Security Architecture of the Java Platform
- 1:21The Evolution of the Java Security Model
- 2:25Goal of the Java Security Model
- 3:01Defined Security Model
- 6:26Security Manager
- 6:50The Security Manager
- 7:23Access Controller Api
- 7:37How Does the Security Sandbox Model Look like
- 12:10Execution Threat
- 15:00The Security Model of the Java Platform
- 22:00Permission Checking
- 23:25Access Controller Instance
- 29:03Java Cryptography Architecture
- 30:49Certificate Revocation Check
- 31:56Sasal Api
- 32:51Best Practices
related talks
44mJava Code Security
52mSecurity Control Enhancements
44mPractical security in a modular world
26mFinding Alternatives to Security Manager
42mHidden security features of the JVM - everything you didn’t know and more
51mJava - Integrity by Default
40mMaximizing Security with JDK: Understanding Built-in Capabilities
37mKeeping Your Java Applications Secure - Cryptographic Improvements and Best Practices