410 likes | 630 Views
Sicherheit bei Enterprise JavaBeans. Überblick. Kurze Einführung in EJB Sicherheit bei EJB Client-Tier Webclient-Server Applicationclient-Server Mid-Tier 3 players Message-Driven Beans Container-Container Legacy-Tier RBAC. Kurze Einführung in EJB.
E N D
Überblick • Kurze Einführung in EJB • Sicherheit bei EJB • Client-Tier • Webclient-Server • Applicationclient-Server • Mid-Tier • 3 players • Message-Driven Beans • Container-Container • Legacy-Tier • RBAC
Kurze Einführung in EJB • J2EE Spezifikation für Verteilte Geschäftsapplikationen (1.4) • Beinhaltet neben Komponenten- (EJB 2.1) auch Serverspezifikation • Wozu eigentlich J2EE EJB-Architektur? • Verteilung, Skalierung, Portabilität • Vereint Java-Technologien (JDBC,JSP...) • Server interagiert mit Ressourcen • einfache Komponenten-Programmierung
Kurze Einführung in EJB • Viele verschiedene Anbieter für Server-Implementierungen. z.B. BEA, Sun, IBM, JBoss... (Problem: Sicherheit anders gehandhabt) • J2EE von Sun bietet Implementierung („for educational purposes“) eines Servers+Tools
Kurze Einführung in EJB • Beans kommunizieren immer über den Container • mit Container-/Serverdiensten (javax.ejb.EJBContext) • mit anderen Beans (JNDI) • „container mediation“ erlaubt Komponenten-Einstellungen außerhalb des Codes
Drei Arten von Beans • Sessionbean (ShoppingCart) • Entitybean (Kunde, Auftrag,...) • Message-Driven Bean (JMS) (Reisebuchung) Kommunizieren mit dem Container über „callBack-Methoden“ (java.ejb-Interfaces / javax.ejb.EJBContext)
Players in the EJB Lifecycle • Bean Provider • Application Assembler • Bean Deployer Sie alle spielen eine spezifische Rolle in der Applikationssicherheit (deployment descriptor)
deployment descriptor • XML-Dokument. (Version 1.0 noch serialisiertes Objekt.) • Kommunikation zwischen 3 players • Container erhält Informationen über Beans bzw. Applikation • Sicherheit • Persistenz • Transaktionen ...
Konzept der Client-Aufrufe über JNDI // Set up the environment properties Hashtable h = new Hashtable(); h.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory"); h.put(Context.PROVIDER_URL,"t3://localhost:7001"); // Get an InitialContext InitialContext initialContext = new InitialContext(h); ... // Get reference to Home Interface orderHome = (OrderHome)initialContext.lookup(„app/Order“);
Wo sind „Angriffspunkte“? • Client-Server (Perimeter) • Innerhalb des Servers (zwischen Beans und Containern) • Server und Legacy-Systemen • 3 Players
Überblick über die Sicherheit bei EJB • Programmatische Sicherheit (javax.ejb.EJBContext) • DeklarativeSicherheit (method permissions) • Rollenbasierter Zugriff • Security Identity propagation (java.security.Principal) (Bean hat in Container Access Control Entries) • Seit 2.1 Client-Authentisierung mit JAAS (über SSL) • Spezifikation erfordert Tool für rollenbasiertes Zugriffssystem (principal-to-role-mapping)
Richtlinien • So wenig programmatic security wie möglich (oft aber nicht machbar) • Stattdessen container-managed (entlastet Programmierer) Ziel: Konfiguration durch Endnutzer
Client-Server • Nach Authentisierung sind einem Client-Subject (mehrere) „Principals“ und „Credentials“ (PK, Zertifikate,Passwort usw.) zugeordnet. • Principals sind Rollen zugeordnet (principal-to-role-mapping) • Security Identity Propagation
Webclient-Server • Firewall • SSL-Verbindung (J2EE: X.509 Server Certificate muss installiert sein) • 3 Arten von Authentisierung (exemplarisch an J2EE): • http (name-passwort, optional SSL) • formular (umfangreicher konfigurierbar, optional SSL) • client-certificate (mutual authentication, X.509 certificate)
Applicationclient-Server • JAAS (verschiedene Loginmodule: name/password, Chipkarte...). • Die Loginmodule steuern Loginvorgang: Applikationen implementieren javax.security.auth.callback.CallbackHandler interface. ( Loginmodul unabhängig)
Mid-Tier Security • 3 Players • Bean provider • Application Assembler • Deployer • Container-Container • Message-Driven Beans
Bean provider • Soll „am wenigsten“ mit Sicherheitsfragen belangt werden (hat ja auch keine Ahnung vom Einsatzort) • Situationen erfordern aber evtl. programmatische Sicherheit (Tageszeit, Bestellungen über 5000 Euro)
Bean provider • Muss logische Rollen verteilen (im Kontext des Codes/Beans, z.B cust,admin,...) • Rollenreferenzen : ... <security-role-ref> <description> This role encompasses the administrators of the on-line shopping company. </description> <role-name>admin</role-name> </security-role-ref> ...
Bean provider Programmatic • Programmierer kann über den Container feststellen, in welcher Rolle der Aufrufende ist • ejbContext.getCallerPrincipal() (java.security.Principal) • ejbContext.isCallerInRole(“Kunde”); • httpServletRequest.isUserInRole(“Kunde”); • Kann Programmierer geheime Rollen einführen? • Buch: „The best course is to build your own EJBs or purchase ones that avoid application level security.“(S.39)
Application Assembler • Erzeugt spezifische Rollen für den deployer, die u.A. auf denen des Programmierers aufsetzen. • Hat die Aufgabe, dem deployer das Rollenmodell zu spezifizieren • Deklariert, welche Methoden von welcher Rolle aufgerufen werden können (deployment descriptor)
Deployer • Ist auf Spezifikation des Produktes angewiesen • Muss Hersteller vertrauen können • Ordnet Benutzer/Gruppen den vorgegebenen Rollen zu bzw. erzeugt neue Rollen • Realms (Serverspezifisch)
Message-Driven Beans • JMS Message Provider in Server integriert (resource adapter) • Messages selbst enthalten keinen Sicherheitskontext • Assembler kontrolliert den Fluss der Nachrichten: • deklariert logische Queue-Namen • bindet consumer an diese Queue-Namen
Message-Driven Beans Deployment-descriptor des Producers: … <message-destination-ref> <message-destination-ref-name>jms/StockInfo</message-destination-ref-name> <message-destination-type>javax.jms.Queue</message-destination-type> <message-destination-link>EmailMDB</message-destination-link> <message-destination-link>QueryMDB</message-destination-link> </message-destination-ref> … Consumer-Programm: // Look up the JMS StockQueue in the environment. Object result = initCtx.lookup("java:comp/env/jms/StockInfo"); // Convert the result to the proper type. javax.jms.Queue queue = (javax.jms.Queue)result;
Message-Driven Bean Deployment-descriptor des Consumers: <ejb-jar> <enterprise-beans> <message-driven> <ejb-name>EmailMDB</ejb-name> <ejb-class>com.customware.ejb.EmailMDB</ejb-class> <transaction-type>Container</transaction-type> <message-destination> <message-destination-name>EmailMDB</message-destination-name> <message-destination-type>javax.jms.Queue</message-destination-type> </message-destination> <message-destination-ref> <message-destination-link>jms/StockInfo</message-destination-link> <message-destination-usage>Consumes</message-destination-usage> </message-destination-ref> <security-identity> <run-as-specified-identity> <role-name>system</role-name> </run-as-specified-identity> </security-identity> </message-driven> </enterprise-beans> </ejb-jar>
Message-Driven Beans • Deployer muss Einstellungen des Assemblers verifizieren (J2EE.5.6.3) • Server muss Tools dafür bereitstellen
Container-Container • Server-spezifisch • Trust relationship zwischen Containern (z.B über SSL mutual authentication) • Seit 2.0: Interaktion zwischen Containern mit CORBA Transport-Protokoll IIOP (Internet Inter-ORB Protocol über TCP/IP)
Container-Container • Genauer: CSIv2 (Common Secure Interoperability version 2) , erlaubt Authentisierungs- und Authorisationsdaten • RMI (Remote Method Invocation) über IIOP (keinen Platz für Sicherheitsinformationen) • Ist in Server implementiert (+SSL)
Legacy-Tier über Resource-Adapter (password/Kerberos) • Container-managed javax.resource.cci.Connection cx = cxf.getConnection(); • Bean-managed properties.setUserName("..."); //from credentials properties.setPassword("..."); javax.resource.cci.Connection cx = cxf.getConnection(properties);
Skalierung und RBAC • RBAC0 • User - User • Rollen - Rollen • Permissions - <method-permission>
Fazit/Diskussion • Skalierung des Zugriffsschutzes? • „Einfach“? • Sicherheitslücken?