Archiv

Archive for the ‘Weblogic Server’ Category

Using JMS Unit-of-Order in a High Availability Environment

Abstract

 

The WLS JMS Unit-of-Order feature (UOO) is well documented in various papers and blogs; it mainly enables numerous message producer to group messages into a single unit that is processed sequentially in the order the messages were created. Until message processing for a message is complete, the remaining unprocessed messages for that Unit-of-Order are blocked. This behavior makes the usage of UOO essential in cases that a specific processing order must be adhered to.

But what happens in a High Availability Environment using distributed queues, when a node breaks down? How can the processing order be guaranteed under these circumstances? This article is a practice report answering these questions.
 

Preparing the test

 

For our tests we are using an OSB cluster with two nodes and an Admin server in the Version 11.1.1.7; the WLS is in the version 10.3.6.

Configuring the JMS Server

Use the Admin Console (Admin Server) to perform the following steps:

  1. Define a data source (e.g. jdbc/jmsDS)
  2. Define a persistence store on each OSB Cluster-Node using the data source from Step1

e.g.:

- JDBCStore4JMS1 targets osb_server1 (migratable)

- JDBCStore4JMS2 targets osb_server2 (migratable)

pic1

  1. Define a JMS Server on each OSB Cluster Node targeting a migratable target. Note: When a JMS server is targeted to a migratable target, you have to use a custom persistence store which must be configured and targeted to the same migratable target.

pic2

  1. Define a JMS Module targeting both JMS Servers; define an appropriate connection factory and a distributed queue.

pic3

pic4

  1. Pointing at the distributed queue, you can now see both queues and the messages holding by them

pic5
 

Performing the test

 

A message producer sends 14 messages using UOO KEY1, KEY2, and KEY3 in the following way:

  • 3 messages with UOO: KEY1
  • 2 messages with UOO: KEY2
  • 9 messages with UOO: KEY3

The following was observed:

  1. The messages were received by the queue and distributed to the configured persistence stores
  2. Messages with the same UOO were stored in the same persistence store
  3. After a cluster node was shut down, all new messages containing the same UOO as those processed by the JMS Server (and the persistence store) pinned to the disconnected node, have been rejected; all other messages continued to be enqueued (and dequeued)
  4. After the migration of the JMS Server (and its persistence store) which was pinned to the shutdown node, to another working node – which took approximately 10 sec.- all rejected messages were processed and the distributed queue regained fully functionality.

 

Conclusion

 

The processing order of messages can be guaranteed in a clustered Environment when using JMS Unit-Of-Order.

If a cluster node crashes the distributed queue is not able to receive messages of a certain UOO for approximately 10 sec. which might be for the most cases a sufficient small amount of time.

Kategorien:Weblogic Server Schlagworte: , ,

IT-Security (Part 7): WebLogic Server, Roles, Role Mapping and Configuring a Role Mapping Provider

Key words: IT-Security, WebLogic Server, Authorization, authorization process, Role Mapping, Roles and  XACML Role Mapping Provider

Let’s continue with Authorization topic. We discussed about the Authorization Process and its main components such as WebLogic Security Framework and Security Provider. Now, we look at Security Provider’s subcomponents: Role Mapping and Security Policies.  

The Role Mapping: Is access allowed?

Role Mapping providers help to clear, weather a user has the adequate role to access a resource? The Authorization provider can with this role information answer the “is access allowed?” question for WebLogic resources.[1]

The Role Mapping Process

Role mapping is the process whereby principals are dynamically mapped to security roles at runtime. The WebLogic Security Framework sends Request Parameter to specific Role Mapping provider that is configured for a security realm as a part of an authorization decision. Figure 1 Role Mapping Process presents how the Role Mapping providers interact with the WebLogic Security Framework to create dynamic role associations. The result is a set of roles that apply to the principals stored in a subject at a given moment.[2]

 

Role Mapping Process

Role Mapping Process

Figure 1 Role Mapping Process

Let’s review each part again[3]:

  • The request parameters are including information such as the subject of the request and the WebLogic resource being requested.
  • Role Mapping provider contains a list of the roles. For instance, if a security policy specifies that the requestor is permitted to a particular role, the role is added to the list of roles that are applicable to the subject.
  • As response, get WebLogic Security Framework the list of roles.
  • These roles can then be used to make authorization decisions for protected WebLogic resources, as well as for resource container and application code. I’m going to discuss about that in part 9.

Configuring a Role Mapping Provider

The XACML Role Mapping provider and DefaultRoleMapper are included by WebLogic Server. In addition, you can use a custom Role Mapping provider in your security realm too. By default, most configuration options for the XACML Role Mapping provider are already defined. However, you can set Role Mapping Deployment Enabled, which specifies whether or not this Role Mapping provider imports information from deployment descriptors for Web applications and EJBs into the security realm. This setting is enabled by default. In order to support Role Mapping Deployment Enabled, a Role Mapping provider must implement the DeployableRoleProvider SSPI. Roles are stored by the XACML Role Mapping provider in the embedded LDAP server.[4] XACML Role Mapping provider is the standard Role Mapping provider for the WebLogic Security Framework. To configure a Role Mapping provider:

  • In the Change Center of the Administration Console, click Lock & Edit

Change Center

Change Center

Figure 2 Change Center

  • In the left pane, select Security Realms and click the name of the realm you are configuring.

Domain Structure: Click Security Realms

Domain Structure: Click Security Realms

Figure 3 Domain Structure: Click Security Realms

 

Summary of Security Realms

Summary of Security Realms

Figure 4 Summary of Security Realms

 

  • Select Providers > Role Mapping. The Role Mapping Providers table lists the Role Mapping providers configured in this security realm

myrealm: Role Mapping

myrealm: Role Mapping

Figure 5 myrealm: Role Mapping

  • Click New. The Create a New Role Mapping Provider page appears.

WebLogic Server default Role Mapping Provider: XACMLRoleMapper

WebLogic Server default Role Mapping Provider: XACMLRoleMapper

Figure 6 WebLogic Server default Role Mapping Provider: XACMLRoleMapper

  • In the Name field, enter a name for the Role Mapping provider. From the Type drop-down list, select the type of the Role Mapping provider (e.g. DefaultRoleMapper or XACMLRoleMapper) and click OK.

a New Role Mapping Provider: Default_1

a New Role Mapping Provider: Default_1

Figure 7 a New Role Mapping Provider: Default_1

 

  • Select Providers > Role Mapping and click the name of the new Role Mapping provider to complete its configuration.

 

Role Mapping Configuration

Role Mapping Configuration

Figure 8 Role Mapping Configuration

  • Optionally, under Configuration > Provider Specific, set Role Deployment Enabled if you want to store security roles that are created when you deploy a Web application or an Enterprise JavaBean (EJB) (See Figure 8 Role Mapping Configuration).
  • Click Save to save your changes.
  • In the Change Center, click Activate Changes and then restart WebLogic Server.

XACML Role Mapping Provider

As we discussed above, a WebLogic security realm is configured by default with the XACML Role Mapping provider. It implements XACML 2.0, the standard access control policy markup language (the eXtensible Access Control Markup Language). WebLogic XACML Role Mapping Provider is saved as a .dat file und available on e.g.: $Domain-Home/XACMLRoleMapper.dat and has the following options (see Figure 8 Role Mapping Configuration):

  • Name: The name of your WebLogic XACML Role Mapping Provider.
  • Description: The description of your Weblogic XACML Role Mapping Provider.
  • Version: The version of your Weblogic XACML Role Mapping Provider.
  • Role Deployment Enabled: Returns whether this Role Mapping provider stores roles that are created while deploying a Web application or EJB.

You can see file structure on the following example: XACMLRoleMapper.dat has different User/Groups. For each User assigned particular Roles, Policies and associated resources. For example, you see description of Group and User “Administrators” below:

XACMLRoleMapper.dat: description of Group and User “Administrators”

XACMLRoleMapper.dat: description of Group and User “Administrators”

Figure 9 XACMLRoleMapper.dat: description of Group and User “Administrators”

You see a policy contains Description, Target and Rule. Each element is associated to different attributes and with this form prepared one “authorization matrix” that it helps to decide Application Server about a user or a group. Continued…

References

See too last parts of IT-Security and Oracle Fusion Middleware:

  1. http://thecattlecrew.wordpress.com/2014/02/17/it-security-weblogic-server_1/ 
  2. http://thecattlecrew.wordpress.com/2014/03/05/it-security-part-2-weblogic-server-and-oracle-platform-security-services-opss-2/ 
  3. http://thecattlecrew.wordpress.com/2014/03/14/it-security-part-3-weblogic-server-and-java-security-features/ 
  4. http://thecattlecrew.wordpress.com/2014/06/05/it-security-weblogic-server-and-authentication-part-4/  
  5. http://thecattlecrew.wordpress.com/2014/06/22/it-security-part-5-weblogic-server-perimeter-authentication-and-identity-assertion/
  6. http://thecattlecrew.wordpress.com/2014/07/23/it-security-part-6-weblogic-server-and-authorization/

[1] Oracle® Fusion Middleware Securing Oracle WebLogic Server 11g Release 1 (10.3.6), E13707-06

[2] Oracle® Fusion Middleware Understanding Security for Oracle WebLogic Server 11g Release 1 (10.3.6), E13710-06

[3] Oracle® Fusion Middleware Understanding Security for Oracle WebLogic Server 11g Release 1 (10.3.6), E13710-06

[4] Oracle® Fusion Middleware Securing Oracle WebLogic Server 11g Release 1 (10.3.6), E13707-06

IT-Security (Part 6): WebLogic Server and Authorization

Key words: IT-Security, WebLogic Server, WebLogic Security Framework, Authorization, authorization process, Role Mapping, Roles, Adjudication Process, Security Service Provider Interfaces (SSPIs), Users, Groups, Principals and Subjects

We discussed about Authentication in Part 4 and 5[1]; now let us focus on Authorization topic. Authorization is known as access control too and is used to clear main questions such as: “What can you access?”, “Who has access to a WebLogic resource?”, “Is access allowed?” and in general “Who can do what?“ In order to guarantee integrity, confidentiality (privacy), and availability of resources, WebLogic are restricted accesses to these resources. In other words, authorization process is responsible to grant access to specific resources based on an authenticated user’s privileges.

Authorization: What can you access?

After authentication one user, it is the first question that system has to answer: “What can you access?” In this sense, WebLogic Server has to clear, which resources are available for a particular user, that will be cleared by using the user’s security role and the security policy assigned to the requested WebLogic resource. A WebLogic resource is generally understood as a structured object used to represent an underlying WebLogic Server entity, which can be protected from unauthorized access using security roles and security policies. WebLogic resource implementations are available for[2]:

  • Administrative resources
  • Application resources
  • Common Object Model (COM) resources
  • Enterprise Information System (EIS) resources
  • Enterprise JavaBean (EJB) resources
  • Java Database Connectivity (JDBC) resources
  • Java Messaging Service (JMS) resources
  • Java Naming and Directory Interface (JNDI) resources
  • Server resources
  • Web application resources
  • Web service resources
  • Work Context resources

The Authorization Process

I’m going to clear whole process in a top-down approach. First of all, we have to see what will be happen in Authorization Process? Figure 1 Authorization Process[3] shows how WebLogic Security Framework communicated with a particular Security Provider and Authorization providers respectively.

 

Authorization Process

Authorization Process

Figure 1 Authorization Process

If a user want to use one protected resource, then WebLogic send a request to “Resource Container” that handles the type of WebLogic resource being requested receives the request (for example, the EJB container receives the request for an EJB resource). It forwards to “WebLogic Security Framework” and its request parameters, including information such as the subject of the request and the WebLogic resource being requested. The Role Mapping providers use the request parameters to compute a list of roles to which the subject making the request is entitled and passes the list of applicable roles back to the WebLogic Security Framework. On this information will be decided about authorization: e.g. PERMIT and/or DENY. WebLogic Server provides an auditing to collect, store and distribute information about requests and outcomes. It calls Adjudication. It can happened that for Authorization is defined multiple providers. For such cases is an Adjudication provider available. The WebLogic Security Framework delegates the job of merging any conflicts in the Access Decisions rendered by the Authorization providers to the Adjudication provider. It resolves the conflicts and sends a final decision (TRUE or FALSE) to WebLogic Security Framework.[4]

WebLogic Security Framework

I have mentioned a bit about WebLogic Security Framework in Part 1 and 2[5]. Figure 2 WebLogic Security Service Architecture shows a high-level view of the WebLogic Security Framework. The framework contains interfaces, classes, and exceptions in the weblogic.security.service package. The Framework provides a simplified application programming interface (API) that can be used by security and application developers to define security services. Within that context, the WebLogic Security Framework also acts as an intermediary between the WebLogic containers (Web and EJB), the Resource containers, and the security providers[6].

WebLogic Security Framework

WebLogic Security Framework

Figure 2 WebLogic Security Service Architecture

The Security Service Provider Interfaces (SSPIs) can be used by developers and third-party vendors to develop security providers for the WebLogic Server environment[7].

Security Provider

Figure 1 Authorization Process presents Security Provider as next module that provides security services to applications to protect WebLogic resources.  A security provider consists of runtime classes and MBeans, which are created from SSPIs and/or Mbean types. Security providers are WebLogic security providers (provided with WebLogic Server) or custom security providers. You can use the security providers that are provided as part of the WebLogic Server product, purchase custom security providers from third-party security vendors, or develop your own custom security providers.

Roles

In order to complete authorization process, is Role Mapping within security provider necessary. Simple to say, a role mapper maps a valid token to a WebLogic user. Formerly that we focus on Roles, I would like to clarify a few more terms.

Users, Groups, Principals and Subjects

User is an entity that is authenticated in our security provider in last steps (See: Part 4 and 5 – Authentication Process[8]). A user can be a person or a software entity or other instances of WebLogic Server. As a result of authentication, a user is assigned an identity, or principal. A principal is an identity assigned to a user or group as a result of authentication and can consist of any number of users and groups. Principals are typically stored within subjects. Both users and groups can be used as principals by WebLogic Server.

Groups are logically ordered sets of users. Usually, group members have something in common. For example, a company may separate its IT-Department into two groups, Admins and Developers. In this form, it will be possible to define different levels of access to WebLogic resources, depending on their group membership. Managing groups is more efficient than managing large numbers of users individually. For example, an administrator can specify permissions for several users at one time by placing the users in a group, assigning the group to a security role, and then associating the security role with a WebLogic resource via a security policy. All user names and groups must be unique within a security realm[9].

Security Roles

Role is a dynamically computed privilege that is granted to users or groups based on specific conditions. The difference between groups and roles is that a group is a static identity that a server administrator assigns, while membership in a role is dynamically calculated based on data such as user name, group membership, or the time of day. Security roles are granted to individual users or to groups, and multiple roles can be used to create security policies for a WebLogic resource. A security role is a privilege granted to users or groups based on specific conditions[10].

Like groups, security roles allow you to restrict access to WebLogic resources for several users at once. However, unlike groups, security roles[11]:

  • Are computed and granted to users or groups dynamically, based on conditions such as user name, group membership, or the time of day.
  • Can be scoped to specific WebLogic resources within a single application in a WebLogic Server domain (unlike groups, which are always scoped to an entire WebLogic Server domain).

Granting a security role to a user or a group confers the defined access privileges to that user or group, as long as the user or group is “in” the security role. Multiple users or groups can be granted a single security role. It can be summarized as follows:

Groups are static and defined on Domain level (coarse granularity) and Roles are dynamic and defined on Resource level (fine granularity). Continued…

See too last parts of IT-Security and Oracle Fusion Middleware:

  1. http://thecattlecrew.wordpress.com/2014/02/17/it-security-weblogic-server_1/ 
  2. http://thecattlecrew.wordpress.com/2014/03/05/it-security-part-2-weblogic-server-and-oracle-platform-security-services-opss-2/ 
  3. http://thecattlecrew.wordpress.com/2014/03/14/it-security-part-3-weblogic-server-and-java-security-features/ 
  4. http://thecattlecrew.wordpress.com/2014/06/05/it-security-weblogic-server-and-authentication-part-4/  
  5. http://thecattlecrew.wordpress.com/2014/06/22/it-security-part-5-weblogic-server-perimeter-authentication-and-identity-assertion/

[1] See: http://thecattlecrew.wordpress.com/2014/06/05/it-security-weblogic-server-and-authentication-part-4/

and http://thecattlecrew.wordpress.com/2014/06/22/it-security-part-5-weblogic-server-perimeter-authentication-and-identity-assertion/

[2] Oracle® Fusion Middleware Understanding Security for Oracle WebLogic Server, 11g Release 1 (10.3.6), E13710-06

[3] Oracle® Fusion Middleware Securing Oracle WebLogic Server 11g Release 1 (10.3.6), E13707-06

[4] Oracle® Fusion Middleware Securing Oracle WebLogic Server 11g Release 1 (10.3.6), E13707-06

[5] See: http://thecattlecrew.wordpress.com/2014/02/17/it-security-weblogic-server_1/

and http://thecattlecrew.wordpress.com/2014/03/05/it-security-part-2-weblogic-server-and-oracle-platform-security-services-opss-2/

[6] See: http://docs.oracle.com/cd/E24329_01/web.1211/e24484/archtect.htm

[7] See: http://docs.oracle.com/cd/E24329_01/web.1211/e24446/security.htm#autoId3

[8] See: http://thecattlecrew.wordpress.com/2014/06/05/it-security-weblogic-server-and-authentication-part-4/

and http://thecattlecrew.wordpress.com/2014/06/22/it-security-part-5-weblogic-server-perimeter-authentication-and-identity-assertion/

[9] See: http://docs.oracle.com/cd/E28280_01/apirefs.1111/e13952/taskhelp/security/ManageUsersAndGroups.html

[10] See: http://docs.oracle.com/cd/E13222_01/wls/docs81/secwlres/secroles.html

[11] See: http://docs.oracle.com/cd/E13222_01/wls/docs90/secintro/realm_chap.html

You’ve Got Mail: Inbound Email Processing in WLS/OSB integration scenarios

In an integration project we are currently replacing an available integration platform using Oracle Service Bus 11g. Different incoming and outgoing message formats and protocols (HTTP, FTP, SMTP, etc.) are used from the external partners of our customer and therefore have to be supported. With OSB no problem at all, but polling a MS Exchange server for new e-mails is simply not possible with OSB standard tooling. Debt is a bug in MS Exchange server, which advertises that it supports plain authentification for login, but it does not ([1], search for AUTH=PLAIN). So when trying to access an exchange inbox from a proxy service ends up with failures, which cannot be worked around.

So we decided to implement a custom Java service that does the polling, because with plain Java the bug can be worked around by setting the corresponding Java Mail session parameters described in [1]. The challenge from a implementation perspective is that in a clustered environment, a service is in general active on all cluster nodes and so parallel access and therefore multi processing for one specific e-mail is possible. So the service has to be implemented as a Weblogic Singleton service [2] to avoid this. A Singleton service is physically deployed to the cluster and so available on all nodes, but it is only active on one specific cluster node. In case of problems on the node where the service is active, it might be activated on another node in the cluster automatically, depending on the failover configuration in the cluster.

Basically Singleton services may be implemented in two different fashions:

Standalone application

When implementing a Singleton service as a standalone application, it has to be bundled as a JAR-File and must be placed under <DOMAIN_HOME>/lib folder. Dependend third-party libs not provided by Weblogic must be also available within this folder, with a reference in the Singleton JARs manifest. Afterwards the servers has to be restarted and the Singleton service has to be registered in the Cluster using Weblogic Console.

 

SingletonStandaloneConfig

 

Part of an enterprise application

When implementing a Singleton service as part of an enterprise application, it has to be packaged inside an EAR-File which has to be deployed to the cluster. The registration of the Singleton to the Cluster is done by adding an entry to weblogic-application.xml.
<wls:singleton-service>
 <wls:class-name>com.opitzconsulting.mail.MailClientRunner</wls:class-name>
 <wls:name>mail-client</wls:name>
</wls:singleton-service>

Deploying a singleton service as part of an enterprise application is the more flexible alternative and less invasive way regarding changes in the singleton implementation, because a simple redeployment of the application is sufficient. Using the standalone variant, a server restart is needed in case of changes in the Singletons implementation logic. In our concrete scenario we decided to implement the Mail Singleton service as part of an enterprise application.

After deploying the Singleton application to the cluster it will be activated on one of the cluster nodes and starts polling the specified email account. When stopping the server, where the Singleton service is currently active on, it will be deactivated on this node and directly be activated on another node. Observing the server logs shows this behaviour because of corresponding log outputs in the Singleton implementations activate() and deactivate() methods.

osb_server1.out

23:20:04.341 [[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  MailClientRunner - SingletonService MailClientRunner is initiated...
23:20:05.461 [[ACTIVE] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  MailClientRunner - SingletonService MailClientRunner is activated...
23:20:06.736 [[ACTIVE] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  MailReaderClient - FROM: ["Bernhardt, Sven" <Sven.Bernhardt@opitz-consulting.com>]
23:20:06.736 [[ACTIVE] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  MailReaderClient - SENT DATE: [Sat Jul 12 23:15:03 CEST 2014]
23:20:06.736 [[ACTIVE] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  MailReaderClient - SUBJECT: [Singleton Service Testmail]
23:20:07.001 [[ACTIVE] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  MailReaderClient - CONTENT: [Hello,

this is a test mail.

BR,
Sven
]

23:21:16.131 [[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  MailClientRunner - SingletonService MailClientRunner has been deactivated...
osb_server2.out

23:21:22.967 [[STANDBY] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  MailClientRunner - SingletonService MailClientRunner is activated...
23:21:24.220 [[STANDBY] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  MailReaderClient - FROM: ["Bernhardt, Sven" <Sven.Bernhardt@opitz-consulting.com>]
23:21:24.220 [[STANDBY] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  MailReaderClient - SENT DATE: [Sat Jul 12 23:15:03 CEST 2014]
23:21:24.220 [[STANDBY] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  MailReaderClient - SUBJECT: [Singleton Service Testmail]
23:21:24.481 [[STANDBY] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  MailReaderClient - CONTENT: [Hello,
this is a test mail.

BR,
Sven
]
Finally let’s have a short look on the implementation of the Singleton service:
package com.opitzconsulting.mail;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import weblogic.cluster.singleton.SingletonService;

public class MailClientRunner implements SingletonService {

private static final Logger log = LoggerFactory.getLogger(MailClientRunner.class.getSimpleName());

private MailReaderClient mailReaderClient;

public MailClientRunner() {

log.info(String.format("SingletonService MailClientRunner is initiated..."));
}

@Override
public void activate() {

log.info(String.format("SingletonService MailClientRunner is activated..."));

mailReaderClient = new MailReaderClient();
mailReaderClient.readMail();
}

@Override
public void deactivate() {

log.info(String.format("SingletonService MailClientRunner has been deactivated..."));
}
}

The interaction between Oracle Service Bus and the Singleton Mail service has been implemented using JMS Queues. The Mail service reads the mails, coverts the content (CSV, XML) from the mail body or from attachments, creates a uniform message format which is independent from protocol as well as format and enqueues it into the corresponding queues. From here OSB dequeues the messages and does the further processing. The logic from this point on is the same, used for other interfaces. With this implementation approach, by combining the strenghts of of JEE and OSB, we created a flexible, maintainable and standard-based way to integrate inbound email processing in our final integration architecture.

Links:

JAX-WS: How to input and output XML AnyType

JAX-WS works in a very simple and effective way if you have defined all objects in a XML Schema definition. But sometimes you can’t define a schema for an operation because e.g. it is a generic operation and accepts or returns dynamic XML.

Nevertheless we would like to use for this operation the same tool chain with JAX-WS which is working perfectly for other operations.

In the first step we define the interface of the operation testXMLCall in the WSDL (better the XSD referenced by the WSDL).

1 <xsd:element name='testXMLCall'> 2 <xsd:complexType> 3 <xsd:sequence> 4 <xsd:element minOccurs='1' maxOccurs='1' name='name' type='xsd:string'/> 5 <xsd:element minOccurs='1' maxOccurs='1' name='requestXMLData' type='xsd:anyType'/> 6 </xsd:sequence> 7 </xsd:complexType> 8 </xsd:element> 9 <xsd:element name='testXMLCallResponse'> 10 <xsd:complexType> 11 <xsd:sequence> 12 <xsd:element minOccurs='1' maxOccurs='1' name='responseXMLData' type='xsd:anyType'/> 13 </xsd:sequence> 14 </xsd:complexType> 15 </xsd:element>

From this WSDL we generate the interface PortType of the webservice. The implementation of the interface needs an operation of this definition:

1 @WebMethod(action = "http://localhost/testXMLCall") 2 @WebResult(name = "responseXMLData", targetNamespace = "http://opitz-consulting.com/interfaces/TestMessages/V1") 3 @RequestWrapper(localName = "testXMLCall", targetNamespace = "http://opitz-consulting.com/interfaces/TestMessages/V1", className = "com.oc.soa.sample.ws.v1.messages.TestXMLCall") 4 @ResponseWrapper(localName = "testXMLCallResponse", targetNamespace = "http://opitz-consulting.com/interfaces/TestMessages/V1", className = "com.oc.soa.sample.ws.v1.messages.TestXMLCallResponse") 5 public Object testXMLCall( 6 @WebParam(name = "name", targetNamespace = "http://opitz-consulting.com/interfaces/TestMessages/V1") 7 String name, 8 @WebParam(name = "requestXMLData", targetNamespace = "http://opitz-consulting.com/interfaces/TestMessages/V1") 9 Object requestXMLData);

We make an implementation:

1 @WebMethod(action = "http://localhost/testXMLCall") 2 @WebResult(name = "responseXMLData", targetNamespace = "http://opitz-consulting.com/interfaces/TestMessages/V1") 3 @RequestWrapper(localName = "testXMLCall", targetNamespace = "http://opitz-consulting.com/interfaces/TestMessages/V1", className = "com.oc.soa.sample.ws.v1.messages.TestXMLCall") 4 @ResponseWrapper(localName = "testXMLCallResponse", targetNamespace = "http://opitz-consulting.com/interfaces/TestMessages/V1", className = "com.oc.soa.sample.ws.v1.messages.TestXMLCallResponse") 5 public Object testXMLCall( 6 @WebParam(name = "name", targetNamespace = "http://opitz-consulting.com/interfaces/TestMessages/V1") 7 String name, 8 @WebParam(name = "requestXMLData", targetNamespace = "http://opitz-consulting.com/interfaces/TestMessages/V1") 9 Object requestXMLData) { 10 TestXMLCallResponse result = new TestXMLCallResponse(); 11 if (requestXMLData instanceof Element) { 12 Element requestXMLDataElement = ((Element) requestXMLData); 13 LOG.info("XML in: \n" + getPrintString(requestXMLDataElement)); 14 XmlObject xmlResult; 15 try { 16 xmlResult = doSomething(requestXMLDataElement); 17 } catch (RuntimeException e) { 18 LOG.error("Error while doSomething with XML: \n" + getPrintString(requestXMLDataElement), e); 19 throw e; 20 } 21 LOG.info("XML out: \n" + getPrintString(xmlResult.getDomNode())); 22 result.setResponseXMLData(xmlResult.getDomNode().getFirstChild()); 23 } else if (requestXMLData == null) { 24 LOG.error("Data is null." ); 25 } else { 26 LOG.error("Unknown data of type '"+ requestXMLData.getClass() + "'." ); 27 } 28 return result; 29 }

We make an implementation of the method getPrintString for a readable output of the XML.

1 public static String getPrintString(Node node) { 2 try { 3 DOMSource domSource = new DOMSource(node); 4 StringWriter writer = new StringWriter(); 5 StreamResult result = new StreamResult(writer); 6 TransformerFactory tf = TransformerFactory.newInstance(); 7 Transformer transformer = tf.newTransformer(); 8 transformer.transform(domSource, result); 9 writer.flush(); 10 return writer.toString(); 11 } catch (TransformerException e) { 12 LOG.warn("Unable to convert XML-Node '" + node.toString() + "' of class '" + node.getClass() + "' to string representation.", e); 13 return "[non printable xml]"; 14 } 15 }

And finally the method doSomething processing the xml element and returning an XmlObject needs to be implemented.

Bernhard Mähr @ OPITZ-CONSULTING published at http://thecattlecrew.wordpress.com/

Kategorien:English, SOA, Weblogic Server

IT-Security: Part 1 to 5 as PDF file

Key words:IT-Security, Security Challenges, OPSS Architecture, WebLogic Server, JAAS, JAAS LoginModules, Authentication, Basic Authentication, Certificate Authentication, Digest Authentication, perimeter Authentication and Identity Assertion

Until now I have published five parts of a series of articles on IT-Security and Oracle Fusion Middleware:

  1. http://thecattlecrew.wordpress.com/2014/02/17/it-security-weblogic-server_1/
  2. http://thecattlecrew.wordpress.com/2014/03/05/it-security-part-2-weblogic-server-and-oracle-platform-security-services-opss-2/
  3. http://thecattlecrew.wordpress.com/2014/03/14/it-security-part-3-weblogic-server-and-java-security-features/
  4. http://thecattlecrew.wordpress.com/2014/06/05/it-security-weblogic-server-and-authentication-part-4/
  5. http://thecattlecrew.wordpress.com/2014/06/22/it-security-part-5-weblogic-server-perimeter-authentication-and-identity-assertion/

I’m going to continue the IT-Security’s articles and you can access to complete first five parts as PDF-file here:

WebLogic-Server_IT_Security_1til5

IT-Security (Part 5): WebLogic Server, perimeter Authentication and Identity Assertion

I tried to discuss about “perimeter authentication” in one extra part of IT-Security’s blogs, because this authentication’s process is an essential approach in a heterogonous world of systems, applications and technologies that they need to trust and communicate to each other.  Generally, we discussed about perimeter authentication, if a remote user requires an asserted identity and some form of proof material to an authentication server that performs the verification and then passes an artifact, or token, to the application server domain.[1]

If we want to identify a remote user outside of the WebLogic server domain, as an authentication server, then we need to another approach for authenticating’s process instead basic authentication with username and password[2]. This authentication’s process is called perimeter authentication. It establishes trust via a passphrase, e.g. tokens. Tokens will be generated as part of the authentication process of users or system processes and could have many different types and / or vendors, e.g. Kerberos and Security Assertion Markup Language (SAML). WebLogic Server is able to use the token(s) so that users are not requested to sign on more than once.

This form of authentication operates with authentication agent. It performs an authentication process that outcomes in a token. It contains the authentication information of user and guarantees for the user’s identity. The Figure1 Perimeter Authentication[3] presents the sequence of events in authenticating process:

Remote User sends a request with passphrase to Authentication Agent. It creates a token and sends to WebLogic Server to access resources and / or application(s). The WebLogic Server perform perimeter authentication via Identity Assertion.

Perimeter Authentication

Perimeter Authentication

Figure 1 Perimeter Authentication

We can define the Identity Assertion provider, as a specific form of Authentication provider that permits users or applications to assert their identity using tokens. With other words, it supports user’s mappers, which map a valid token to a WLS-User. It is possible to develop your own or use a third-party security vendor’s Identity Assertion providers. Identity assertion can use perimeter authentication schemes such as the Security Assertion Markup Language (SAML), the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO), or enhancements to protocols such as Common Secure Interoperability (CSI) v2 and support single sign-on.[4]  The WebLogic Identity Assertion providers support the following token types[5] (here is a selected list of token types):

  • AU_TYPE, for a WebLogicAuthenticatedUserused as a token.
  • X509 is an ITU-T standard for a public key infrastructure (PKI) and Privilege Management Infrastructure (PMI) and RFC 4158 provides information and guidance for certification path building.[6]
  • X509_TYPE, for an X509 client certificate used as a token:
  • CSI_X509_CERTCHAIN_TYPE, for a CSIv2 X509 certificate chain identity used as a token.

“The Negotiate Identity Assertion provider is used for SSO with Microsoft clients that support the SPNEGO protocol. The Negotiate Identity Assertion provider decodes SPNEGO tokens to obtain Kerberos tokens, validates the Kerberos tokens, and maps Kerberos tokens to WebLogic users. The Negotiate Identity Assertion provider utilizes the Java Generic Security Service (GSS) Application Programming Interface (API) to accept the GSS security context via Kerberos. The Negotiate Identity Assertion provider is for Windows NT Integrated Login.” [7]

  • AUTHORIZATION_NEGOTIATE, for a SPNEGO internal token used as a token.
  • WWW_AUTHENTICATE_NEGOTIATE, for a SPNEGO internal token used as a token.

“The SAML Identity Assertion providers handle SAML assertion tokens when WebLogic Server acts as a SAML destination site. The SAML Identity Assertion providers consume and validate SAML assertion tokens and determines if the assertion is to be trusted (using either the proof material available in the SOAP message, the client certificate, or some other configuration indicator).”[8]   I am going back to SAML topic in an additional article(s).

  • SAML_ASSERTION_B64_TYPE, for a Base64 encoded SAML.assertion used as a token.
  • SAML_ASSERTION_DOM_TYPE, for a SAML DOM element used as a token.
  • SAML_ASSERTION_TYPE, for a SAML string XML form used as a token.
  • SAML2_ASSERTION_DOM_TYPE, for a SAML2 DOM element used as a token.
  • SAML2_ASSERTION_TYPE, for a SAML2 string XML form used as a token.
  • SAML_SSO_CREDENTIAL_TYPE, for a SAML string consisting of the TARGET parameter concatenated with the assertion itself and used as a token.

I introduced about Digest Authentication[9] in previous blog and WebLogic supports für Web Service application the following Digest type:

  • WSSE_PASSWORD_DIGEST_TYPE, for a username token with a password type of password digest used as a token.

 

The Authentication and Identity Assertion Process

Now, we can compare Basic authentication Process with Identity Assertion Process. On Figure 2 Authentication Process (Principal Validation Process)[10] shows the authentication process for a fat-client login. A user attempts to log into a system using a username/password combination. WebLogic Server establishes trust by calling the configured Authentication provider’s LoginModule, which validates the user’s username and password and returns a subject that is populated with principals per Java Authentication and Authorization Service (JAAS) [11] requirements. In this way, an authentication context will be established and user can access to certain resource and / or components in WebLogic Domain.

 

Authentication Process (Principal Validation Process)

Authentication Process (Principal Validation Process)

Figure 2 Authentication Process (Principal Validation Process)

Figure 3 Perimeter Authentication presents the perimeter authentication process[12].

  1. A token from outside of WebLogic Server is passed to an Identity Assertion provider that is responsible for validating tokens of that type and that is configured as “active”.
  2. If the token is successfully validated, the Identity Assertion provider maps the token to a WebLogic Server username, and sends that username back to WebLogic Server, which then continues the authentication process as described above. It requires the same components, but also adds an Identity Assertion provider. Specifically, the username is sent via a Java Authentication and Authorization Service (JAAS)CallbackHandlerand passed to each configured Authentication provider’s LoginModule, so that the LoginModule can populate the subject with the appropriate principals.

 

Perimeter Authentication

Perimeter Authentication

Figure 3 Perimeter Authentication

If you compare the two ways of authentication, then you can find out a core security characteristic of WebLogic Server too. It is mean; WebLogic Server security architecture has a consistence modular structure and therefore can response rapid to new challenges and technologies in security area. This architecture is capable to expand its features und integrate new security components in itself.

 

[1] Oracle® Fusion Middleware: Understanding Security for Oracle WebLogic Server, 11g Release 1 (10.3.6), E13710-06

[2] For „Basic Authentication: Username/Password“ see: http://thecattlecrew.wordpress.com/2014/06/05/it-security-weblogic-server-and-authentication-part-4/

[3] Oracle® Fusion Middleware: Understanding Security for Oracle WebLogic Server, 11g Release 1 (10.3.6), E13710-06

[4] Oracle® Fusion Middleware Developing Security Providers for Oracle WebLogic Server, 11g Release 1 (10.3.6), Part Number E13718-05, http://docs.oracle.com/cd/E23943_01/web.1111/e13718/ia.htm

[5] Oracle® Fusion Middleware Developing Security Providers for Oracle WebLogic Server, 11g Release 1 (10.3.6), Part Number E13718-05, http://docs.oracle.com/cd/E23943_01/web.1111/e13718/ia.htm

[6] See: http://tools.ietf.org/html/rfc4158

[7] Oracle® Fusion Middleware Developing Security Providers for Oracle WebLogic Server, 11g Release 1 (10.3.6), Part Number E13718-05, http://docs.oracle.com/cd/E23943_01/web.1111/e13718/ia.htm

[8] Oracle® Fusion Middleware Developing Security Providers for Oracle WebLogic Server, 11g Release 1 (10.3.6), Part Number E13718-05, http://docs.oracle.com/cd/E23943_01/web.1111/e13718/ia.htm

[9] See http://thecattlecrew.wordpress.com/2014/06/05/it-security-weblogic-server-and-authentication-part-4/

[10] See: http://docs.oracle.com/cd/E23943_01/web.1111/e13718/atn.htm#i1141106

[11] IT-Security (Part 3): WebLogic Server and Java Security Features: http://thecattlecrew.wordpress.com/2014/03/14/it-security-part-3-weblogic-server-and-java-security-features/

[12] See http://docs.oracle.com/cd/E23943_01/web.1111/e13718/ia.htm

Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 26 Followern an