Monday, July 28, 2014

Understanding OAM 11g ASDK Configuration and Cert Requirements

Oracle provides documentation on developing an Access Client for the OAM 11g ASDKhttp://docs.oracle.com/cd/E40329_01/dev.1112/e27134/as_api.htm#autoId0, but getting it to work can be challenging when running the Access Servers in Simple or Cert Mode.  In this article I will not explain how to create an Access Client, there are already good examples out there for that.  What I want to cover is the correct structure of the Access Client configuration including all the required files and code snippets to hopefully save you a lot of time.

Wednesday, June 25, 2014

Monitoring OIM R2 PS2 Orchestration

The OIM R2 PS2 (11.1.2.2.0) release provides a great new feature: monitoring of OIM orchestration processes through Enterprise Manager console.

Such feature provides the capability of querying orchestration data to check orchestration processes details. For example, you can check what happened during a user modification operation, or you can get details of failed orchestration processes, such details can help you to fix issues in your environment. It is also possible to check configuration information, like which event handlers are defined for a specific orchestration process.

Thursday, June 5, 2014

Presenting the new IDM Deployment Wizard

Introduction

With the recent IDM 11gR2PS2 release Oracle has developed a new deployment tool that aims to automate and reduce the time required to install and configure Oracle Identity and Access Management Components.

In this post we are going to present the benefits, supported topologies and components, and key points to keep in mind to conduct a successful IDM deployment.

Logging in OIM custom code

Proper logging is one of the main considerations during custom development. This is no different in OIM projects in which custom code is being developed and deployed to OIM. Proper logging is fundamental part of development, helping in finding issues, fixing them and also in reporting relevant runtime conditions.

This post shows how to leverage the Oracle Fusion Middleware infrastructure in which OIM runs in order to create proper logging information from custom code. It is not the intent of this post to cover all logging considerations; there are plenty of materials on the internet and book stores to cover the basics.

Friday, May 23, 2014

OAG/OES Integration for Web API Security: skin and guts

Introduction


When it comes to defining a strategy for web API security, OAG (Oracle API Gateway) and OES (Oracle Entitlements Server) together present a very interesting choice and are a very powerful combination indeed.

In this post we're going to take a look at what each component brings in (the skin) and then get our hands on actually describing the integration in detail (the guts).

OAG is designed to inspect and act on various types of messages that are delivered to it or just pass through it. It's usually positioned to be deployed on the DMZ (the De-Militarized Zone) within corporate networks. As such, it can block malicious traffic, authenticate users with a variety of protocols, integrate with anti-virus products, perform message throttling, thus delivering only the good stuff to your intranet servers and also off-loading them, decisively contributing to achieve some IT operational SLAs. More than that, OAG can switch protocols and transform messages. For instance, an organization may have SOAP-based web services and want to expose them as REST without any re-writing. Or implement SAML federation without touching origin systems. Or talk Kerberos or OAuth with clients and speak SAML with back-end servers. Or use it as an FTP server so that incoming files are immediately sent to a processing pipeline. The possibilities are numerous. Having mentioned these few features and examples, it's not unreasonable to think deploying OAG inside intranets. And that's not unusual, actually. It is a nice bridge with obvious benefits.

OES is designed to provide fine-grained authorization with externalized policies to client applications. It takes the coding of access decisions away from developers. Besides the obvious security pro, it shortens the change cycle, when a new security policy needs to be deployed. You simply avoid going through all the phases required for re-deploying your application just because of that change. It's true the new policy needs testing, but that's nowhere near when compared to what it takes to re-deploy a new application version. The time to market is drastically reduced. Now to the fine-grained part. OES can take a bunch of aspects in consideration when authorizing: the user identity, user roles, user attributes, context information about the request being made (like originating IP address), factors external to the request (like time of day, day of week, etc) and, of course, request data. Those combined makes it a very powerful authorization engine. It's not coincidence that OES is the component behind OAM's (Oracle Access Manager) authorization engine.

While OAG itself brings in authorization capabilities, in this field OES offers a much richer model. And if the organization already employs OES elsewhere, integrating it with OAG makes a lot of sense, because we end up with a single and consistent approach for authorization across applications.