Archiv

Posts Tagged ‘Security’

IT-Security (Part 2): WebLogic Server and Oracle Platform Security Services (OPSS)

OPSS Architecture

As we discussed (http://modj.org/home/aktueles/it-security-weblogic-server-and-oracle-platform-security-services-opss/e17330b741d0e387ead1a36591466a7c.html), OPSS is Oracle proposals regarding enterprise security services. It is as a framework that provides a comprehensive set of security services. These services based on Java technologies and have a consistent approach for design and apply security policies to Java EE and resources. We look at OPSS architecture from two different perspectives, which are connected to each other very closely. I try to review the advantages of OPSS for developers and administrators from Application’s perspective and present the cooperating of technology components such as LDAP, Application Server and Oracle Fusion Middleware from Component’s perspective. Thereby, we can determine the main OPSS’s benefits that Oracle says:

  • Allows developers to focus on application and domain problems
  • Supports enterprise deployments
  • Supports several LDAP servers and SSO systems
  • Is certified on the Oracle WebLogic Server
  • Pre-integrates with Oracle products and technologies

Application’s point of view

Oracle Platform Security Services (OPSS) is both a security framework exposing security services and APIs, and a platform offering concrete implementation of security services. It includes these elements:

  • Common Security Services (CSS), the internal security framework on which Oracle WebLogic Server is based
  • Oracle Platform Services
  • User and Role APIs
  • Oracle Fusion Middleware Audit Framework

Figure 1 Application’s perspective  illustrations OPSS‘s architecture from application point of view. Such architecture allows OPSS to support different security and identity systems without changing the APIs. OPSS is integrated with Oracle Fusion Middleware‘s management tools to administrate and monitor the security policies implemented in the underlying identity management infrastructure.  Therefore, OFM technologies such as Oracle SOA, Oracle WebCenter Suite, Oracle Application Development Framework (ADF), Oracle Web Services Manager (OWSM) and… could use OPSS capacities.

OPSS offers abstraction layer APIs those isolate developers from security and identity management implementation details. In this way, developer can invoke the services provided by OPSS directly from the development environment (e.g. JDeveloper) using wizards. Admin can configure the services of OPSS into the WLS. As you see in Figure, the uppermost layer consists of Oracle WebLogic Server and the components and Java applications running on the server; below this is the API layer consisting of Authentication, Authorization, CSF (Credential Store Framework), and User and Role APIs, followed by the Service Provider Interface (SPI) layer and the service providers for authentication, authorization, and others. The final and bottom layer consists of repositories including LDAP and database servers.

Figure 1 Application's perspective

Figure 1 Application’s perspective

 OFM-Component’s point of view

Figure 2 OFM-Component’s perspective shows the various security components as layers. The top layer includes the OPSS security services; the next layer includes the service providers, and the bottom layer includes the OPSS security store with a repository of one of three kinds. OPSS provides auditing capabilities for components too.

The second layer [Security Services Provider Interface (SSPI)] has the capability that works with Java EE container security – named Java Authorization Contract for Containers (JACC) mode and in resource-based (non-JACC) mode, and resource-based authorization for the environment.

SSPI is a set of APIs for implementing pluggable security providers. A module implementing any of these interfaces can be plugged into SSPI to provide a particular type of security service. Therefore, OPSS has a consistent structure and is able to meet the requirements for integrating JEE Applications generally and specially OFM-Components and Oracle Security technologies, such as OAM, OID and so on.

Figure 2 OFM-Component's perspective

Figure 2 OFM-Component’s perspective

References

IT-Security: WebLogic Server and Oracle Platform Security Services (OPSS)

17. Februar 2014 6 Kommentare

IT security is popular in a way never known before! I love it!

If I discussed e.g. in a WebLogic Server workshop about that, I heard normally form administrators: That’s not my thing, forget it! But newly, everybody wants to know “how can we secure our data and our information?!”  To be honest, you need to detect your application server that you are using, and if you are not able to use WebLogic Server security features, then this could be your problem.

WebLogic Server uses a security architecture that provides a unique and secure foundation for applications that are available via the Web. It is designed for a flexible security infrastructure and enabled to response the security challenges on the Intra- and Internet. We are able to use security capacity of WebLogic Server as a standalone feature to secure WebLogic Server and/or as part of a corporation-wide, security management system.

Overview

In order to achieve a satisfactory level of security, we have to design an integrated security policy: from lack of resources till the increasing complexity of IT systems. The elementary principles in IT security are Confidentiality and/or privacy, availability and integrity. Confidentiality and/or privacy mean information that has to be protected against unauthorized disclosure. Availability means services; IT system functions and information must be available to users when they need it. Integrity means data must be complete and unaltered.  Therefore, we understand security policy as a policy that it covers protection objectives and broad-spectrum security measures in the sense of the acknowledged requirements of an organization.

Simple to say, security is the protection of information that needs to protected, from unauthorized access. IT security could be helped us through technology, processes, policies and training, so that we can be sure that data stored and secured in a computer or passed between computers is not compromised.  Therefor data encryption is the first step in the direction IT-Security. In order to access to specific resources, user needs to provide (normally) his user name and password. Data encryption is the transformation of data into a form that cannot be understood without decryption key(s).

Security Challenges

In a world that we used to work with distributed IT-landscape, we face to with different challenges, e.g. network-based Attacks, heterogeneity on application layer from user interface till to application.  It is really difficult to stay on a standard security level for all of team members of development team. We cannot awaiting all of application developers to be able develop solve the security challenges such as privacy, identity management, compliance, audit too.  Another area is interfaces between application server and backend database.

A simple case is presented on the following diagram: most applications are multi-tiered and distributed over several systems. A client invokes an application or sends a request to server. This case presents how many systems are in transaction involve.  We have to check all of critical points and interfaces: network-based attacks, user interface, application Server and so on.

See: http://modjorg.files.wordpress.com/2014/02/security_challenges_1.jpg

On these grounds, we need to use an enterprise security framework that allows application developers to pick and choose from a full set of reusable and standards based security services that allow security, privacy, and audit. Oracle Platform Security Services (OPSS) is a security framework that runs on WebLogic Server and is available as part of WebLogic Server. It combines the security features of BEA‘s internal security (WLS + Oracle Entitlement Server (OES)) and the OAS (Hava Platform Security (JPS) – earlier JAZN) to provide application developers, system integrators, security administrators, and independent SW vendors with a comprehensive security platform framework for Java SE and Java EE applications. In this form, Oracle is able to suggest a uniform enterprise security policy and a self-contained and independent framework with Identity management and audit services across the enterprise. The heart of whole system beats on WebLogic Server.

WebLogic Server provides authentication, authorization, and encryption services with which you can guard these resources. These services cannot provide protection, however, from an intruder who gains access by discovering and exploiting a weakness in your deployment environment. Therefore, whether you deploy WebLogic Server on the Internet or on an intranet, it is a good idea to contact an independent security expert to go over your security plan and procedures, audit your installed systems, and recommend improvements.

References

OWSM Custom Assertion zur Absicherung einzelner Services per IP-Adresse

An diesem Beispiel soll die Erstellung einer OWSM (Oracle Web Services Manager) Custom Assertion vorgestellt werden. Die Custom Assertions erlauben es, nahezu beliebige Policies zu erstellen, die wie die von Oracle vorgefertigten Policies auf Service-Endpunkte, SOA Komponenten oder auch Service-Referenzen angewendet werden können. Typischerweise kümmern sich diese Policies um Authentifizierung und Autorisierung.

Unser Anwendungsfall: wir möchten einen bestimmten Service nur für bestimmte IP-Adressen zugreifbar machen. Die Vorstellung ist, dass wir eine Liste mit gültigen IP-Adressen für den jeweiligen Service konfigurieren. Alle Requests, die von anderen Adressen kommen, sollen abgelehnt werden.

Diese Funktionalität ist in der SOA Suite leider nicht Out-Of-The-Box vorhanden.

1. Projekt-Setup

Um das Projekt aufzusetzen wird in JDeveloper einfach ein Standard-Java-Projekt erstellt.

Bevor die Entwicklung starten kann, müssen einige Bibliotheken für OWSM und SOA in den Build-Pfad eingebunden werden. Die genaue Beschreibung spare ich mir an dieser Stelle – wer möchte kann jederzeit die aktuelle Liste aus dem fertigen Projekt (siehe unten) kopieren (Tipp: Einfach die .jpr-Datei mit einem Texteditor bearbeiten und sämtliche Library References rüberkopieren – nach einem Refresh in JDev, sind die Bibliotheken dort bekannt).

2. Grundstruktur der Assertion-Klasse

Grundsätzlich ist eine Custom Assertion lediglich eine einzige Klasse, die von oracle.wsm.policyengine.impl.AssertionExecutor erbt. Hier ist unser erstes Grundgerüst:

public class ClientIpAssertion extends AssertionExecutor {
    private final static Logger LOG = Logger.getLogger(ClientIpAssertion.class.getName());
 
    protected IAssertion mAssertion = null;
    protected IExecutionContext mEcontext = null;
    protected oracle.wsm.common.sdk.IContext mIcontext = null;

    public IResult execute(IContext iContext) {

       // Hier wird die Assertion ausgefuehrt
    }
 
    public void init(IAssertion iAssertion, IExecutionContext iExecutionContext, IContext iContext) {
        mAssertion = iAssertion;
        mEcontext = iExecutionContext;
        mIcontext = iContext;
    }
 
    public void destroy() {
    }
}

Die Methode init() wird vom OWSM zum Initialisieren aufgerufen. Hier kommen schonmal grundsätzlich einige Umgebungsobjekte mit, die später noch wichtig sind, um z.B. die Parameter auszulesen.

Die Methode destroy() wird beim Zerstören der Klasse aufgerufen. Falls man irgendwelche Ressourcen belegt hat, kann man diese hierin freigeben.

3. Metadaten

Neben der Implementierung der Assertion benötigt man noch eine XML-Datei (ClientIpAssertion.xml) mit einigen Metadaten zur Assertion.

<orawsp:AssertionTemplate xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy"
                          orawsp:Id="ClientIp"
                          orawsp:attachTo="generic" orawsp:category="security"
                          orawsp:description="Client IP assertion verifies the client IP address to be in a configured list of addresses"
                          orawsp:displayName="Client IP"
                          orawsp:name="custom/CientIp"
                          xmlns:custom="http://schemas.oracle.com/ws/soa/custom">
  <custom:custom-executor orawsp:Enforced="true" orawsp:Silent="false"
                   orawsp:category="security/custom"
                   orawsp:name="WSSecurity_Custom_Assertion">
    <orawsp:bindings>
      <orawsp:Implementation>com.opitzconsulting.clientipassertion.ClientIpAssertion</orawsp:Implementation>
      
      <orawsp:Config orawsp:configType="declarative" orawsp:name="ClientIp">
        <orawsp:PropertySet orawsp:name="clientip">
          <orawsp:Property orawsp:contentType="required"
                           orawsp:name="allowedIpAddresses" orawsp:type="string">
            <orawsp:Value>127.0.0.1</orawsp:Value>
          </orawsp:Property>
        </orawsp:PropertySet>
      </orawsp:Config>
    </orawsp:bindings>
  </custom:custom-executor>
</orawsp:AssertionTemplate>

Hierin wird z.B. die ID der Assertion festgelegt (hier: “ClientIp”), woran die Policy angehängt werden kann (hier: “generic”, sprich kann überall verwendet werden – man könnte es auch auf Service-Endpunkte, SOA Komponenten oder SOA Referenzen einschränken) und weitere allgemeine Infos wie ein Anzeigename, Beschreibung, usw.

Im Tag “orawsp:Implementation” wird der vollständige Name der Implementierungsklasse angegeben. Besonders interessant ist der nächste Abschnitt, der die möglichen Konfigurationsparameter der Assertion zusammen mit Standardwerten enthält. Hier: Ein Parameter “allowedIpAddresses” vom Typ “string” mit dem Standardwert “127.0.0.1″.

Diese Konfigurationsparameter können später im Enterprise Manager konfiguriert werden, wenn man sich aus den Assertions eine eigene Policy zusammenbaut (siehe Deployment).

4. IP-Vergleich

Kommen wir zum Kern der Assertion: Vergleich der Client IP Addresse mit einer Liste von erlaubten IP-Addressen. Da dieser Vergleich für jeden Aufruf ausgeführt werden muss, erfolgt die Implementierung vollständig in der execute()-Methode.

 public IResult execute(IContext iContext) {
        IResult result = new Result();
        result.setStatus(IResult.FAILED);
 
        // Abschnitt A
        IMessageContext.STAGE stage = ((IMessageContext)iContext).getStage();
        LOG.fine("stage=" + stage);
        if (stage != IMessageContext.STAGE.request) {
            LOG.fine("Nothing to process on this stage");
            result.setStatus(IResult.SUCCEEDED);
            return result;
        }
        
        // Abschnitt B
        SOAPBindingMessageContext soapbindingmessagecontext = (SOAPBindingMessageContext)iContext;
 

        String remoteAddress = soapbindingmessagecontext.getRemoteAddr();
        String[] allowedIpAddresses = new String[] { "127.0.0.1" };
 
        boolean clientIpValid = false;
        for (String allowedIpAddress : allowedIpAddresses) {
            if (allowedIpAddress.equals(remoteAddress)) {
                clientIpValid = true;
            }
        }
 
        // Abschnitt C
        if (clientIpValid) {
            result.setStatus(IResult.SUCCEEDED);
        } else {
            WSMException exception = new WSMException("Client IP address " + remoteAddress + " is not allowed");
            result.setFault(exception);
            result.setStatus(IResult.FAILED);
        }
 

        return result;
    }

Als allererstes initialisieren wir ein IResult-Objekt mit einem Fehlerstatus – per Default soll ein Fehler zurückkommen.

Im Abschnitt A geht es zunächst darum, zu prüfen, in welchem Stage wir uns befinden. Die Policy wird grundsätzlich für Request und Reply ausgeführt. Da für unsere Policy nur der Request Stage interessant ist geben wir für alle anderen Fälle ein SUCCEEDED zurück und beenden an dieser Stelle die Bearbeitung.

In Abschnitt B holen wir uns zuerst die Remote IP Addresse aus dem SOAPBindingMessageContext. Hinweis: Es könnte auch sein, dass hier kein SOAPBindingMessageContext vorliegt, falls der Aufruf nicht über ein SOAP Binding erfolgt, sondern z.B. über ein Direct Binding. Dieser Fall wird hier vernachlässigt.

Dann legen wir – vorerst hardcodiert – ein Array mit gültigen IP-Adressen ein. Trifft der Vergleich einer IP-Adresse dieser Liste mit der Remote-Adresse zu, so wird die Variable clientIpValid auf true gesetzt.

In Abschnitt C wird ein entsprechendes Result gesetzt auf Basis von clientIpValid. Interessant ist hier vor allem der Fehlerfall. Hier sollte man eine brauchbare Fehlerbeschreibung eintragen, da diese bei Fehlschlag an den Aufrufer zurückgesandt wird. Hinweis: Es gibt keinen Flow Trace und keine Composite Instance, falls eine der eingehenden Policies fehlschlägt – dadurch wird diese Fehlermeldung doppelt wichtig, wenn man nicht lange Zeit Logs durchwühlen möchte.

Die Assertion kann nun deployed werden und wird nur noch Requests von 127.0.0.1 durchlassen.

5. Parameter übergeben

Natürlich wollen wir die IP-Adressen nicht hardcodieren, vor allem, weil man dann für jede Änderung der IP-Adressen die komplette SOA Suite neustarten müsste – außerdem kann man die Assertion dann nicht wiederverwenden.

Wir haben den Parameter in den Metadaten oben bereits definiert. Nun brauchen wir also noch eine Möglichkeit, diesen in der Assertion auszulesen. Dazu verwenden wir folgendes Code-Schnipsel:

    private Properties configProps = new Properties(); 

    private void retrieveConfiguration() {
        IAssertionBindings bindings = ((SimpleAssertion)(mAssertion)).getBindings();
        if (bindings != null) {
            List<IConfig> cfgl = bindings.getConfigs();
            if (!cfgl.isEmpty()) {
                IConfig cfg = cfgl.get(0);
                List<IProperty> configProperties = cfg.getProperties();
                if (configProperties != null) {
                    for (IProperty configProperty : configProperties) {
                        String propName = configProperty.getName();
                        String propValue = configProperty.getValue();
                        if (propValue == null || propValue.trim().isEmpty())
                            propValue = configProperty.getDefaultValue();
                        if (propValue != null)
                            configProps.setProperty(propName, propValue);
                    }
                }
            }
        }
    } 

 

    public void init(IAssertion iAssertion, IExecutionContext iExecutionContext, IContext iContext) {
        mAssertion = iAssertion;
        mEcontext = iExecutionContext;
        mIcontext = iContext;
        retrieveConfiguration(); // Dieser Aufruf wurde hinzugefügt
    }

Diese Methode sollte am Besten aus der init()-Methode aufgerufen werden, da OWSM die init()-Methode immer aufrufen wird, wenn eine Änderung der Konfiguration erfolgt und sich somit die Policyversion erhöht.

Nun stehen alle Properties in dem privaten Property-Objekt configProps und können von dort verwendet werden. Da wir davon ausgehen, dass hier eine “,”-separierte Liste mit IP-Adressen drin steht, ersetzen wir unsere zuvor hardcodierte Liste durch folgendes:

     String[] allowedIpAddresses = 
                 ScenarioUtils.getConfigPropertyValue(
                     "allowedIpAddresses", 
                     soapbindingmessagecontext, 
                     configProps, 
                     null)
                 .split(",");

Und schon wird die konfigurierte Liste an erlaubten Adressen für die Prüfung herangezogen.

6. Deployment

Das Deployment erfolgt mit den folgenden Schritten:

  • JAR mit der Assertion in DOMAIN_HOME/lib kopieren
  • SOA Suite neustarten
  • Im EM unter Weblogic-Domain -> Web Services -> Policies -> Assertion Templates die Assertion importieren (ClientIpAssertion.xml)
  • Im EM unter Weblogic-Domain -> Web Services -> Policies eine neue Policy erstellen
  • In die Policy die Assertion “custom/ClientIp” einfügen und unten unter “Assertion-Inhalt” die Liste mit IP-Addressen vom Standard-Wert aus abändern

Nun kann die Policy analog anderer Sicherheitspolicies an Service-Endpunkte angehängt werden, die dann nur noch von bestimmten IP-Adressen aus aufgerufen werden können.

Zusammenfassung

Die Entwicklung eigener Policies ist immer dann hilfreich, wenn man in der SOA Suite eine bestimmte Anforderung in Bezug auf Security umsetzen möchte, die nicht Out-Of-The-Box geboten ist. Auf diese Weise haben wir beispielsweise auch eine Weitergabe der Authentifizierung im Payload realisiert, so dass unsere BPEL-(Geschäfts-)Prozesse frei von Authentifizierungsdetails bleiben.

Das komplette Projekt mit der oben erstellen Policy gibt es hier zum Download:
ClientIPAssertion.zip

Kategorien:JDeveloper, Oracle SOA Suite Schlagworte: , ,
Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.