Logging made easy in OAM 11g with this simple trick!

INTRODUCTION   This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available. Logging is extremely helpful when trying to troubleshoot issues and normally when you see instructions to log in OAM 11g […]

Strategies for managing OAAM to OAM connections in production

Many Oracle Access Management 11g customers opt to deploy a combination of Oracle Access Manager and Oracle Adaptive Access Manager using the Advanced Integration option. This combination of product features can provide strong, adaptive authentication and fraud mitigation for online applications. In this post, we examine a number of strategies for configuring the connectivity between […]

File Permission / Access issue when Installing OGG on Windows Servers running Oracle DB

Introduction It is common to receive permission errors in the capture/extract process of Oracle GoldenGate (OGG) running on Microsoft Windows servers with Oracle Database. The capture process reads the Oracle redo and archive logs to find the committed transactions. When an Oracle Database is installed on Windows servers, the redo logs and the archive log directory are […]

How to secure Web Services exposed by OAAM Server (oaam_server)

At the end it turned out very simple but I had spent long time in configuring security (authentication and authorization) for Web Services exposed by OAAM 11gR2, thought about writing a blog post on it. For native integration, OAAM Server (oaam_server) exposes Web Services. For the enterprise deployment, security of Web Services would be mandatory.  […]

Index of Access Management articles

Part 3: OAM11g WNA Identity Store Considerations and Configurations

Introduction This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available. This is the final post of a three part series.  In “Part 1: Under the Covers of OAM11g WNA integration […]

Part 2: How to Configure OAM11g WNA for Multiple AD Forests

Introduction This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy.  An index to the entire series with links to each of the separate posts is available. This is the second post of a three part series.  In “Part 1: Under the Covers of OAM11g WNA integration […]

Protecting Intranet and Extranet Applications with a Single OAM 11g Deployment

I frequently get asked how to setup a single OAM deployment to protect both intranet and extranet apps. Today I’d like to explore the issues and solutions around such a setup.

This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available.

The Requirement

So the specific request is how to set up OAM so that it can protect intranet applications that can be accessed only from within the corporate network and extranet applications that can be accessed from the public internet.

The “Problem”

The issue (or apparent issue) that people see with creating such a solution is that OAM 11g is configured with a single “front end host” configured through a global setting that governs what protocol (HTTP/HTTPS), hostname, and port are used when users must be redirected to the OAM managed server.

If you go back and look at Chris’s post on the OAM 11g login flow and cookies then you’ll see that there are points in the flow where the user is redirected to the OAM managed server. This redirect can be to a load balancer or HTTP server fronting a managed server or cluster of OAM managed servers. So, OAM allows you through the “load balancer” settings to specify the interface that is fronting the OAM manage server(s).

The issue is that there is only a single global setting for defining the front end host for OAM. So people ask how can we protect intranet and extranet applications with one OAM deployment?

There are in fact two solutions to meeting this requirement.

An Extranet Front End Host for OAM

The first solution is to simply specify an extranet (externally accessible) host as the front end host for OAM. This way both intranet users accessing internal applications and extranet users accessing external applications from the internet can access the OAM server through the same front end host.

OAM Deployment with External Front End Host

This architecture is the recommended reference architecture for supporting this requirement. It is also the simplest solution to implement. The idea that you need to wrap your head around here is that even though your application may be accessible only from within the corporate network, that does not mean that your users cannot be sent at times (during login and initial SSO) to an externally accessible web server.

I do sometimes hear objections to this solution from customers who say that they want to keep their intranet users on the internal network. I have to admit that I don’t fully understand this objection. When I inquire as to what specifically they are concerned about I usually get a fairly vague response. In addition, it should be noted that on many if not most corporate networks, the user wouldn’t be sent all the way out to the internet to access the OAM front end host but rather just to the DMZ.

That being said, for customers that really want to keep intranet users on the internal network there is another solution.

Split DNS

I found a really good article by Thomas Schinder that explains split DNS. You can read it here.

The basic idea specific to an OAM deployment is that you setup your DNS so that your front end host for OAM as defined in the load balancer setting (say sso.mycompany.com) resolves to an externally accessible load balancer or web server when users query the host from the public internet but resolves to an internal load balancer or web server when users query the host from the internal network.

OAM Deployment with Split DNS

Split DNS works really well with OAM and is a completely viable option for enabling OAM to protect both extranet and intranet solutions simultaneously.

Identity Stores

There is a second unrelated issue that sometimes faces people wanting to do a single OAM deployment for external and internal applications and that is how their users are stored.

There are many variations on identity store requirements for hybrid internal/external deployments and I will save this discussion for another day but I wanted to mention it now as something to consider if you are planning such a deployment.

Patch Management of an Oracle Identity Management Deployment

Today I’d like to discuss a very important topic which is patch management in an Oracle IDM/IAM deployment.  Patching seems like a pretty basic topic.  It is often taken for granted.  However, experience has shown me that patching is a frequent source of confusion for many enterprise software customers including those deploying the Oracle Identity Management  stack.

So, I thought I’d address some common questions / topics related to patching so that people have a better understanding of what patches to apply to their environments and when to apply them. 

This post is a part of both the OAM 11g academy and OIM 11g academy series.


Patches, Bundle Patches, Patch Sets and New Releases

The first thing I’d like to do is clear up some terminology that is frequently a source of confusion for Oracle Middleware customers.  There are four delivery mechanisms for updating Oracle Fusion Middleware software.

New Releases: New releases are major updates to software.  New releases always include major feature enhancements and can often include new ways of doing existing functionality and even complete new code basis.  Moving to a new release can sometimes be characterized as an upgrade but other times should be considered a migration where the old and new versions of software coexist side-by-side and certain applications, users, or functionality move from the old version of the software to the new release over time.

Patch Sets: The topic of what exactly a patch set constitutes in Fusion Middleware land is somewhat controversial but I’d like to throw out some practical guidelines based on my experience.

For starters, patch sets are applied at the package level.  To review, there are two major packages in the IDM stack today: 1) the IDM package containing OVD, OID, and OIF and 2) the IAM package containing OAM, OIM, and OAAM. 

Patch sets can be packaged as full installs, upgrades using the Oracle installer, or both.
To me, patch sets constitute minor new releases.  They may contain new functionality and may require some “post application” steps to complete the upgrade. 

Patch sets should be fully tested in the context of a customer specific deployment before being moved into production.

Bundle Patches: Bundle patches are sets of patches that fix multiple issues that are applied primarily through the OPatch utility.  Bundle patches usually do not contain new features and require few if any manual post application steps.

Bundle patches should also be tested in the context of a customer specific deployment before being applied to production systems but should be considered lower risk than patch sets.

One-Off Patches: One-off patches are patches for individual issues or very small sets of issues.  They are often issued to individual customers only.

What patches should I apply?

Now that we’ve cleared up terminology I’ll give some guidance on what patches one should be looking to apply.

In terms of patch sets.  I recommend that you apply the latest patch set for the release you are installing when doing a new deployment with the caveat that all the software being installed into one Fusion Middleware Home (or WebLogic domain) must be running compatible versions.  I discuss the issue of compatible versions extensively in my articles on domain architecture.

Beyond that, I strongly recommend that customers apply the latest bundle patches for every Oracle Identity Management product they are installing unless they have an explicit reason not to.

OAM, OIM, OIA, OAAM, and OES, have official bundle patches.  There are good support articles detailing the bundle patch histories of each product with links to the bundle patches available.  I wrote about these support articles here.  The link given to the OAM article is still valid.  The link given to the OIM article is for 11.1.1.3 only.  There is a separate article (1360009.1) for OIM 11.1.1.5.

The situation is a little trickier for OID, OVD, and their management application ODSM.  Traditionally these components have only been patches through one-off patches.  However, recently (what I like to call) pseudo bundle patches for these components have emerged for Fusion Apps build outs.

Even though these pseudo bundle patches are listed as Fusion Apps only, the earliest version of these patches was also recommended for non-FA deployments in the IDM Enterprise Deployment Guide.  Based on this fact and the content of the patches, I recommend that customers seriously consider applying the latest OID, OVD, and ODSM pseudo bundle patch.

You can find the specific IDs for these patches in the Fusion Application release notes (1355561.1).  Early versions of these patches were also mentioned in the 11.1.1.5 IDM EDG

At the time of this article, the current versions of these patches seem to be:

12937765 for OID 11.1.1.5.   This is the same patch recommended in the 11.1.1.5 EDG.

13031079 for ODSM 11.1.1.5.  This is a more updated version of the ODSM patch recommended in the EDG.

13031196 for OVD 11.1.1.5.  This is a more updated version of the OVD patch recommended in the EDG. 

If you are doing an FA install or EDG style build out with OAM/OIM integration.  It is also important that you apply the IDM Tools patch for the ‘IDM Config Tool’.  The idmConfigTool is a command line utility used to automate portions of an OAM/OIM deployment.  It is very important that you apply the recommended patch for this tool before trying to use it.

Unfortunately, the guidance on what patch ID to apply for the IDM Tools for non-FA installs is a little weak.  My current recommendation is to apply the most recent patch available for the version of OAM/OIM that you are installing (11.1.1.5 or 11.1.2).  If you have trouble identifying the right patch then I encourage you to reach out to support.

When should I apply patches in a new deployment?

In general, you should apply patches in a new build out after you have installed the software components you are deploying but before you create, extend, and configure the WLS domains.  Likewise, you should apply patches before creating instances for OID, OVD, and OHS.  It should be noted that my recommendation is in line with the sequence of events documented in the IDM EDG and more updated IDM EDG for FA.

Now, I’m not saying that you have to re-install if you don’t follow this order.  However, installing the patches this early is a good idea for a few reasons:

1) There could be fixes to the configuration wizard or other configuration tools that are present in the patch.  Applying the patch up front lets you take advantage of these fixes.  Again, this is especially important with the ‘IDM Config Tool’ patch.

2) It’s easier to apply the patches up front as you don’t have any services running that require starting and stopping.

3) If you apply the patches up front then you don’t have to worry about never getting around to it.  Too often I have seen customers continue to delay applying patching during their build outs to the point they go into production without patches that are strongly recommended.

How often should I apply new patches?

The short but obvious answer is as often as possible.  I will say that all too often I see customers struggle with issues that have already been fixed in available bundle patches.  All software includes bugs and as good as Oracle Middleware software is, it is no exception.  Applying regular bundle patches should be considered part of the cost of doing business for your business and the apps that leverage the Oracle IDM stack.

I’d love to see customers apply every bundle patch but I know that many won’t be able to meet that goal.  So, for those that can’t or won’t apply every bundle patch I’d ask you to consider a policy of applying every other patch.  This should put you in the ball park of applying bundle patches every 6-9 months.  I think that is a reasonable thing to suggest.

How to tell what patches have been applied to an environment?

The answer is run ‘opatch lsinventory -all’.  You can read my full blog post on this subject here.

Protecting a WebCenter app with OAM 11g

Last year I wrote an article on OAM and ADF Applications with Anonymous access. This week I did some work with another A-Team guy building on that previous work.The new requirement was that the customer wanted two different portions of the app to be pr…

Sample External Login.jsp page for Oracle Access Manager 11g

One of the more popular posts on our blog was a post I made a while back about how to configure OAM 11g to use an externally hosted custom login page and how to write such a login page.

When I originally wrote that post I included only snippets from a JSP page that represents an external OAM login form.

I have updated that post with a full sample login.jsp that functions as an external login form for OAM 11g.  The code is also included below.

To review, to work as an external login form the login page code must do the following:

• You need to post back to the OAM server to the URI: “/oam/server/auth_cred_submit”. Note that in my sample, I’m posting to a load balancer VIP over SSL which will route the post to one of the OAM servers in my cluster.

• You need to post variables “username” and “password”

• You need code that will grab the request_id off of the query string and post it (as a hidden form variable) as well.

The Code

    <%@ page contentType="text/html; charset=iso-8859-1" language="java" %>
<%
String error=request.getParameter("error");
if(error==null || error=="null"){
error="";
}
String paramName = "request_id";
String reqId = request.getParameter( paramName );

%>
<html>
<head>
<title>User Login JSP</title>
<script>
function trim(s)
{
return s.replace( /^\s*/, "" ).replace( /\s*$/, "" );
}

function validate()
{
if(trim(document.frmLogin.sUserName.value)=="")
{
alert("Login empty");
document.frmLogin.sUserName.focus();
return false;
}
else if(trim(document.frmLogin.sPwd.value)=="")
{
alert("password empty");
document.frmLogin.sPwd.focus();
return false;
}
}
</script>
</head>

<body>
<p>Acme Clinical Applications Login Screen - OAM edition</p>
<p>
&nbsp;
</p>
<div><%=error%></div>
<form name="frmLogin" onSubmit="return validate();" action="http://authbootcamp.us.oracle.com/oam/server/auth_cred_submit" method="post">
<p>
User Name<input type="text" name="username"/><br/>Password &nbsp;<input type="password"
name="password"/>
<input name="request_id" value="<%=reqId%>" type="hidden"> <br/>
</p>
<p>
<input type="submit" name="sSubmit" value="Submit"/>
</p>
</form>
</body>
</html>

Deploying OAM 11g Correctly Part 2 – Logins and SSL

This is another post in our OAM 11g Academy series. To view the first post in the series which will be updated throughout to contain links to the entire series, click here: http://fusionsecurity.blogspot.com/2011/02/oracle-access-manager-11g-academy.html

A couple months ago Chris wrote a good post about the best way to deploy OAM from a web server / network architecture point of view.

Today, I’d like to touch on a very important but overlooked aspect of OAM deployments which is whether or not to use SSL between the web server and OAM. The product documentation and broader OAM writings out there in the community do a good job of describing the webgate to OAM server communication (OAP) security modes of open vs. simple vs. cert mode. However, what is completely neglected is the discussion of whether or not to use SSL between the web server and OAM.

This discussion applies to architectures where the OAM server is being fronted by a web server (usually OHS). This includes Fusion Apps deployments, the integrated IDM deployment described in the IDM Enterprise Deployment Guide (EDG), and many other custom deployments.

OAM 10g vs. 11g

In OAM 10g, users login by submitting credentials to the webate which then passes them along over the OAP protocol to the access server (OAM server equivalent in 10g). So, in 10g it was extra important to use simple mode or cert mode for the webgate to OAM communication if you don’t want credentials going over the wire.

In OAM 11g, users login by submitting credentials directly to the OAM server (running in WLS) which can be exposed directly to the user or put behind a web server (usually OHS). This means 2 things:

1) Credentials are no longer going over the webgate to OAM (OAP) connection. This somewhat lessons the value of using simple or cert mode; although username and response information that potentially carries confidential data still goes over this connection.

2) In the case where OHS is fronting OAM, user credentials are going from OHS to OAM/WLS. This means that if you don’t want those credentials to travel over the wire in the clear, that you should configure this connection to be over SSL.

Recommendation

If your security requirements and network are such that you want to encrypt credentials and other potentially confidential information going between the web server (OHS) and OAM, then you should configure the webgate to OAM communication to be simple or cert mode and configure the OHS to OAM/WLS communication to be SSL (HTTPS).

If your security requirements and network are such that you don’t care about encrypting credentials that go over the wire between the web server (OHS) and OAM then use open mode for the webgate communication and normal HTTP for OHS to OAM/WLS.

The following diagram illustrates both of these options.

I would argue it doesn’t make sense to do what many people do which is to use simple mode for webgate communication but normal HTTP without SSL for web server (OHS) to OAM/WLS communication.

OAM 11g Single Sign-On and OAM 10g Cookies

This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available.

In an earlier post I talked about how cookies work when you’re using OAM 11g server with OAM 11g WebGates. But the OAM 11g server also works with OAM 10g WebGates and there are reasons you’d deploy 10g WebGates today. But OAM 11g and 10g have fundamentally different behavior when it comes to the cookies.

So how do cookies work when you’re using 10g WebGates with the 11g server?

In short they work pretty much the same way. Or at least they can work nearly the same way with 10g WebGates as they do with 11g WebGates.

I setup an environment with two servers – alpha and linux.ktest.oracleateam.com. Alpha is an IIS server with an OAM 10g WebGate and one protected directory which I cleverly named /protected/. The other machine (linux.ktest.oracleateam.com) is, as you’ve guessed, a Linux box with the OAM server installed. I’d include a diagram, but it looks exactly the same as the diagram in the older post.

Here’s what the HTTP traffic looks like when I try to access http://alpha/protected/:



GET /protected/ HTTP/1.1
Accept: image/jpeg, image/gif, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)
Accept-Encoding: gzip, deflate
Host: alpha
Connection: Keep-Alive

HTTP/1.1 302 Redirect
Content-Length: 0
Location: http://linux.ktest.oracleateam.com:14100/oam/server/obrareq.cgi?wh%3Dalpha%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttp%3A%2F%2Falpha%20ru%3D%252Fprotected%252F
Server: Microsoft-IIS/7.5
Set-Cookie: ObSSOCookie=loggedoutcontinue; httponly; path=/
X-Powered-By: ASP.NET
Date: Fri, 09 Mar 2012 16:14:16 GMT

GET /oam/server/obrareq.cgi?wh%3Dalpha%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttp%3A%2F%2Falpha%20ru%3D%252Fprotected%252F HTTP/1.1
Accept: image/jpeg, image/gif, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)
Accept-Encoding: gzip, deflate
Host: linux.ktest.oracleateam.com:14100
Connection: Keep-Alive

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Date: Fri, 09 Mar 2012 16:16:55 GMT
Pragma: no-cache
Content-Length: 3326
Content-Type: text/html; charset=UTF-8
Expires: 0
Set-Cookie: OAM_REQ=VERSION_4~KJTasxCSm1Z1LVGtpMwu5nJ3cwSYLNx1TGFLYN7tRq3Jr1Pin693MMCJJHQ6bPQL1vSxK3En%2bFaQPCNevV3Idi1o07xN9LjfFWubXf4B98yXOGRH6fT7RaZjp2dfPyqCADEG022AZg7xWsrCjff848vcqwAzLXs2schaae8z7YLXxCNVoMUGMsHFahTPkuq31ZIaqK8lZq7glReQuZyiBGXWPr5EptvGcbWEe0X9iOoeiUGFoJt6LpOCz79%2fJPpURizXOCQej3M3eCpGw8QmzUGa5ajAsPu5M0KZPViBubQwM9dsePRYNYaFizHYla8%2ftYr%2fHpgxkNLmuZ3crkzSZES45dnWdaqZBPbAcZb9S8pdGsjxMiB18bcudXC5A4DXnPwYLu92RQKrtHHgiq1JYIfMz4ZsCK5Fks%2bH3waTnw4Ec9V6EFvWF2rHXeGjqsHNN3jdZDtUlRkYcgBffUpBVkd%2fppwds%2fRcS4RVie39kRqduhbS1qphdGdy6pH8cX%2f8LEn3QoR2GXcn8cxgDEtfTR4q2JvrhbSnSChrqX967ogq8b%2bi0HEzDwFkYbhuZudsCXRHPVeOjGe78SY5IumWqCBIxW0z9LiSOhmcBDbagRFByhcTMpHZPU%2fxJxL7vdqllS8BwRPeVZuI0yuGstbBxVgWMzPJD%2bahnJXwlNODHEBCuMtYyO7gTol9VqpJo2l40PUgQUkmtw3cNf%2btazp5uTY%2fy8MG9AAyTNMTlgvaSnNTe0fwxiVMVcjuIqYUl%2fhSy%2fh1Z0lodn0w6HZQoiIyYMiEA%2felDR38iBKP4%2b14IvKroONAhuX0Ly4XSNRqGbzKyt%2fmqkc%2bguL2OPAIFjeBGMuses6r5Ml%2fepyF%2f%2bqnXTBB%2bFweBmaxHdv1uU58kWwtTfkWJwEuALDJhAXG7ixRnkHISfizpkPKGTs5jAGDj8Lhcndl1IAKbekDS5d6g2zxSpl4RDGmZuWcVG2G8XSyBs5D317CWvx1Mq3SDZhcvGy7RscDcqy7ra66j1uS49QaKvAgdGA03RzwAfCLMD4wNnj06aAkh9BXTDv%2bgHYzCaWpXm8yjMAVPr9fhXzn3Nro3ffM8I%2bEdFq2lRLdFIo04Gc4o%2f7lS0dGZKS6%2fyB5UKCtmD%2fihmsHdCVFUcRCMdff21HGT%2f8y0j6yQHNf4X1RefEdYcjbYOEv%2bbm1Jq5zcat60maesmmiBl5n6LJFYSfG6QLs4wLqZjqEXPWU96JBQuFwDjf7ux4RTcmnLG3LbU3M6lUPqfB0k8TGee7XbtaW0Z%2b69CIsYElY1ftvszOT2uMw2yAjy8nvs7iIJVvXGb0yX57h77WiySby6ISqvIH1maMdzr6jIAL76ImMc%2bCVJzJvt4WgobY6nc4OH4MSPMg%3d; path=/; HttpOnly
X-ORACLE-DMS-ECID: bc0b467a62ba363a:-50e866c2:135cc4d3539:-8000-0000000000000ab5
X-Powered-By: Servlet/2.5 JSP/2.1

As is the case with 11g WebGates the WebGate redirects me over to the OAM server to see if I have an existing session. And since I haven’t logged on yet I don’t have a session or associated cookie. So OAM sends me off to the login page.

So far this looks remarkably like the 11g WebGate. And by “remarkably like” I mean exactly the same as!

At this point I’m staring at the login page so let me enter the username and password and POST them to the credential collector:


POST /oam/server/auth_cred_submit HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Referer: http://linux.ktest.oracleateam.com:14100/oam/server/obrareq.cgi?wh%3Dalpha%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttp%3A%2F%2Falpha%20ru%3D%252Fprotected%252F
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Host: linux.ktest.oracleateam.com:14100
Content-Length: 67
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: OAM_REQ=VERSION_4~KJTasxCSm1Z1LVGtpMwu5nJ3cwSYLNx1TGFLYN7tRq3Jr1Pin693MMCJJHQ6bPQL1vSxK3En%2bFaQPCNevV3Idi1o07xN9LjfFWubXf4B98yXOGRH6fT7RaZjp2dfPyqCADEG022AZg7xWsrCjff848vcqwAzLXs2schaae8z7YLXxCNVoMUGMsHFahTPkuq31ZIaqK8lZq7glReQuZyiBGXWPr5EptvGcbWEe0X9iOoeiUGFoJt6LpOCz79%2fJPpURizXOCQej3M3eCpGw8QmzUGa5ajAsPu5M0KZPViBubQwM9dsePRYNYaFizHYla8%2ftYr%2fHpgxkNLmuZ3crkzSZES45dnWdaqZBPbAcZb9S8pdGsjxMiB18bcudXC5A4DXnPwYLu92RQKrtHHgiq1JYIfMz4ZsCK5Fks%2bH3waTnw4Ec9V6EFvWF2rHXeGjqsHNN3jdZDtUlRkYcgBffUpBVkd%2fppwds%2fRcS4RVie39kRqduhbS1qphdGdy6pH8cX%2f8LEn3QoR2GXcn8cxgDEtfTR4q2JvrhbSnSChrqX967ogq8b%2bi0HEzDwFkYbhuZudsCXRHPVeOjGe78SY5IumWqCBIxW0z9LiSOhmcBDbagRFByhcTMpHZPU%2fxJxL7vdqllS8BwRPeVZuI0yuGstbBxVgWMzPJD%2bahnJXwlNODHEBCuMtYyO7gTol9VqpJo2l40PUgQUkmtw3cNf%2btazp5uTY%2fy8MG9AAyTNMTlgvaSnNTe0fwxiVMVcjuIqYUl%2fhSy%2fh1Z0lodn0w6HZQoiIyYMiEA%2felDR38iBKP4%2b14IvKroONAhuX0Ly4XSNRqGbzKyt%2fmqkc%2bguL2OPAIFjeBGMuses6r5Ml%2fepyF%2f%2bqnXTBB%2bFweBmaxHdv1uU58kWwtTfkWJwEuALDJhAXG7ixRnkHISfizpkPKGTs5jAGDj8Lhcndl1IAKbekDS5d6g2zxSpl4RDGmZuWcVG2G8XSyBs5D317CWvx1Mq3SDZhcvGy7RscDcqy7ra66j1uS49QaKvAgdGA03RzwAfCLMD4wNnj06aAkh9BXTDv%2bgHYzCaWpXm8yjMAVPr9fhXzn3Nro3ffM8I%2bEdFq2lRLdFIo04Gc4o%2f7lS0dGZKS6%2fyB5UKCtmD%2fihmsHdCVFUcRCMdff21HGT%2f8y0j6yQHNf4X1RefEdYcjbYOEv%2bbm1Jq5zcat60maesmmiBl5n6LJFYSfG6QLs4wLqZjqEXPWU96JBQuFwDjf7ux4RTcmnLG3LbU3M6lUPqfB0k8TGee7XbtaW0Z%2b69CIsYElY1ftvszOT2uMw2yAjy8nvs7iIJVvXGb0yX57h77WiySby6ISqvIH1maMdzr6jIAL76ImMc%2bCVJzJvt4WgobY6nc4OH4MSPMg%3d

username=weblogic&password=ABcd1234&request_id=-8330979068306697433

HTTP/1.1 302 Moved Temporarily
Connection: close
Date: Fri, 09 Mar 2012 16:17:01 GMT
Transfer-Encoding: chunked
Location: http://alpha/obrar.cgi?cookie=vBDzuSSiKglMEtxbyB1gBqe1aZvsE6WQhSF7%2Be%2FZ0DpntUvIXgPr79acpIo8FQ0V4mvuOrqn%2BGIendMpqPNgTuISUEDblFQjZKfNG4ixWaVW%2BitIr58w%2FvQ2kalnVL3zhKYAF2yU7rGyNolRifidAq7xW8%2BKQbyFq8GFAgga0Assv%2BxwGzvd%2FizmiXnx8cOD6KZBWGMtIeLBrJRBitqXoKgLZc6b2UuCc2VLkTufmlQdt0DZ7dOACr45efkrTSKgKhuqoykTsiKiGTIP4R2xe85TUfYYm%2F1i4E8p%2FdHmcD4tpJ4LRrslKI3MgDHj%2Ft1uq3ryhROxbcRBk2eM1Eo99QYNY6IOsFyo1sJA7YEkr7c%3D%20redirectto=%252Fprotected%252F%20ssoCookie=httponly
Set-Cookie: OAM_ID=VERSION_4~C7Iz5I0rodPWWPLR82CoQg==~bP8dGW/YVqe1NaHiCaZ3z6p2dbxVbpJpcSYMU6LVzUSBHp0C9OtSKbtvUlHHDsGImCi8KtAh3CLHXN+paF2+ZyxNOZOge2Mg2aH6vF8Wy2fUgIEYAVYjtVrP4bVTC0GpM7S6dt3XpjR/AHScYUdQNp5Olr5D3gSlBAnXWcyYxY9u/x620d5LHIYvBdZvqZzVsfAAV/5KovBKD/5wvhPWI/JDkYoUdT37VoaDp7BS1lOumUtTqzXkQTzMzAkLCzhS0M1NyCYTiT9904bIxfzhJw==; path=/; HttpOnly
Set-Cookie: OAM_REQ=invalid; path=/; HttpOnly
X-ORACLE-DMS-ECID: bc0b467a62ba363a:-50e866c2:135cc4d3539:-8000-0000000000000ab7
X-Powered-By: Servlet/2.5 JSP/2.1

Not terribly surprisingly I get an OAM_ID cookie and a redirect back to the protected resource, again just like with the 11g WebGate.

So we’re on our way back to the WebGate to a fake resource called obrar.cgi with some encrypted data in the query string (yes, oddly familiar!).

The browser does the HTTP GET there…


GET /obrar.cgi?cookie=vBDzuSSiKglMEtxbyB1gBqe1aZvsE6WQhSF7%2Be%2FZ0DpntUvIXgPr79acpIo8FQ0V4mvuOrqn%2BGIendMpqPNgTuISUEDblFQjZKfNG4ixWaVW%2BitIr58w%2FvQ2kalnVL3zhKYAF2yU7rGyNolRifidAq7xW8%2BKQbyFq8GFAgga0Assv%2BxwGzvd%2FizmiXnx8cOD6KZBWGMtIeLBrJRBitqXoKgLZc6b2UuCc2VLkTufmlQdt0DZ7dOACr45efkrTSKgKhuqoykTsiKiGTIP4R2xe85TUfYYm%2F1i4E8p%2FdHmcD4tpJ4LRrslKI3MgDHj%2Ft1uq3ryhROxbcRBk2eM1Eo99QYNY6IOsFyo1sJA7YEkr7c%3D%20redirectto=%252Fprotected%252F%20ssoCookie=httponly HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Referer: http://linux.ktest.oracleateam.com:14100/oam/server/obrareq.cgi?wh%3Dalpha%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttp%3A%2F%2Falpha%20ru%3D%252Fprotected%252F
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Cookie: ObSSOCookie=loggedoutcontinue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cache-Control: no-cache
Host: alpha

HTTP/1.1 302 Redirect
Content-Length: 0
Location: /protected/
Server: Microsoft-IIS/7.5
Set-Cookie: ObSSOCookie=vBDzuSSiKglMEtxbyB1gBqe1aZvsE6WQhSF7%2Be%2FZ0DpntUvIXgPr79acpIo8FQ0V4mvuOrqn%2BGIendMpqPNgTuISUEDblFQjZKfNG4ixWaVW%2BitIr58w%2FvQ2kalnVL3zhKYAF2yU7rGyNolRifidAq7xW8%2BKQbyFq8GFAgga0Assv%2BxwGzvd%2FizmiXnx8cOD6KZBWGMtIeLBrJRBitqXoKgLZc6b2UuCc2VLkTufmlQdt0DZ7dOACr45efkrTSKgKhuqoykTsiKiGTIP4R2xe85TUfYYm%2F1i4E8p%2FdHmcD4tpJ4LRrslKI3MgDHj%2Ft1uq3ryhROxbcRBk2eM1Eo99QYNY6IOsFyo1sJA7YEkr7c%3D;httponly; path=/
X-Powered-By: ASP.NET
Date: Fri, 09 Mar 2012 16:14:22 GMT

Ah! There it is – the first real difference between OAM 11g and OAM 10g WebGates behavior. With the 10g WebGate I get a good old ObSSOCookie instead of a 11g’s uniquely named cookie.

I also got and a redirect back to the original resource, which I then retrieve:


GET /protected/ HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Referer: http://linux.ktest.oracleateam.com:14100/oam/server/obrareq.cgi?wh%3Dalpha%20wu%3D%2Fprotected%2F%20wo%3D1%20rh%3Dhttp%3A%2F%2Falpha%20ru%3D%252Fprotected%252F
Accept-Language: en-US
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Cookie: ObSSOCookie=vBDzuSSiKglMEtxbyB1gBqe1aZvsE6WQhSF7%2Be%2FZ0DpntUvIXgPr79acpIo8FQ0V4mvuOrqn%2BGIendMpqPNgTuISUEDblFQjZKfNG4ixWaVW%2BitIr58w%2FvQ2kalnVL3zhKYAF2yU7rGyNolRifidAq7xW8%2BKQbyFq8GFAgga0Assv%2BxwGzvd%2FizmiXnx8cOD6KZBWGMtIeLBrJRBitqXoKgLZc6b2UuCc2VLkTufmlQdt0DZ7dOACr45efkrTSKgKhuqoykTsiKiGTIP4R2xe85TUfYYm%2F1i4E8p%2FdHmcD4tpJ4LRrslKI3MgDHj%2Ft1uq3ryhROxbcRBk2eM1Eo99QYNY6IOsFyo1sJA7YEkr7c%3D
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cache-Control: no-cache
Host: alpha

HTTP/1.1 200 OK
Cache-Control: no-cache,private
Pragma: no-cache
Content-Type: text/html
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Fri, 09 Mar 2012 16:14:22 GMT
Content-Length: 2495

As with the 11g WebGate you probably noticed that there’s no domain= parameter on the cookie. Which means that this ObSSOCookie is specific to the one WebGate. But wait, didn’t OAM 10g WebGates use a domain-wide cookie?

Yes they did. And 10g WebGates still do if (and only if) that’s what you want.

Here’s my configuration settings for my 10g WebGate:

In my case I left out the cookie domain setting for the WebGate. And by doing that I told the WebGate to act like the 11g WebGate and use “host only” cookies.

Filling in that setting changes the behavior. For new deployments of OAM 11g with 10g WebGates I generally would recommend leaving the setting blank because it solves a number of problems with cookies in larger deployments of OAM. But I’m going to put off discussing those problems until a later post.

OAM 11g Policy Model Part 4: Resource Protection Levels and Excluded Resources

This is the 4th post in my series going over the OAM 11g policy model and another post in the broader OAM 11g Academy series. To view the first post on the OAM 11g policy model, as well as the index to the entire OAM 11g Academy series, click here: http://fusionsecurity.blogspot.com/2011/02/oracle-access-manager-11g-academy.html.
 
OAM 11g PS1 (11.1.1.5) introduced two important enhancements related to resource definitions in the policy model:

    1. The ability to optionally include query strings as part of resource definitions.
 
  1. The designation of a protection level for a resource and the completely new concept of excluded resources that go with it.
 

In 11.1.1.3, resources could not include query strings and OAM essentially ignored query strings in its policy evaluation. In 11.1.1.5, there is a specific field for query strings in the resource definition screen of the OAM console that you can optionally make use of. We’ll come back to this in a future post.

For now I’ll point you at the documentation but also point out that you don’t have to define query strings if you don’t want to. Incoming request for resources that include query strings will still resolve to resources that have blank query string parameters. For example, if you define a resource /foo/bar.jsp and leave the query string field blank, it will still match requests for /foo/bar.jsp?x=y and the like.

Protection Levels
With that out of the way, I’d like to talk about the 2nd important enhancement to resource definitions in OAM 11g and that is the notion of protection level and in particular the designation of excluded resources.

When you define a resource in OAM 11g PS1, you specify a protection level from 1 of 3 choices: protected, unprotected, and excluded.

Protected resources must be included in an authentication policy that uses an authentication scheme with a protection level greater than 0. Protected resources can be associated with any authorization policy.

Unprotected resources must be included in an authentication policy that uses an authentication scheme with a protection level of 0. Most often this will be the anonymous authentication scheme. Unprotected resources can be associated with any authorization policy. Indeed, OAM will block access to unprotected resources that are not included in an authorization policy.

However, it is worth noting that it probably doesn’t make sense to put an unprotected resource into an authorization policy with constraints. If you plan on applying constraints to requests to a resource, then you should make that resource protected.

Session validation is still performed on requests to unprotected resource. However, if a user session times out or is otherwise invalidated and a user tries to access an unprotected resource, they will be let through but their name will not be propagated in the OAM_REMOTE_USER header, rather OAM_REMOTE_USE will be set to anonymous.

Basically, unprotected resources are the pre-PS1 equivalent of associating a resource with the anonymous authentication scheme.

Excluded resources are entirely new to PS1 (11.1.1.5). When a request comes in and matches up with a resource that has been designated as excluded, then the webgate/agent just lets the request through.

No calls to the OAM server are made, no session validation is performed, and the OAM_REMOTE_USER header is not added to the request. Also of note, if you have configured your webgates/agents to issue certain cache control headers back to the browser, they will not be issued in the case of excluded resources.

As you can probably see, OAM’s handling of excluded resources is very fast because, well, it isn’t doing much for them.

Unprotected vs. Excluded
At this point (if you are like me) you are probably wondering about when resources should be designated as excluded and when they should be designated as unprotected. On some levels these are very similar designations, although there are some important differences.

For performance reasons, I think it is a good idea to designate as many of your resources as possible as excluded. At the same time you want to make sure that your applications are still secure and functional. So, I’ve come up with the following guidelines:

1) If a resource is private, which is to say only authenticated users should have access to it, then if should be designated as protected.

2) If the resource is public, which is to say that authenticated and unauthenticated users should have access to it but you want to be able to know the names of authenticated users and/or set responses to create headers containing certain information about authenticated users, then the resource should be designated as unprotected.

3) If you want to audit requests to a resource using OAM then a resource should be designated as protected or unprotected. Note that you can still audit using web server logs for excluded resources.

4) If you want session validation to be performed in advance of populating the OAM_REMOTE_USER header, then a resource should be designated as protected or unprotected.

5) A corollary to items 2 and 4 above is that if you want the WLS SSO Synchronization filter to be active and “protect” a resource should be designated as protected or unprotected. This is an important note for those using OAM to protect Oracle WebCenter or ADF based applications.

6) If none of the above are true and you have a resource that is public, that doesn’t need to know anything about the user, where you don’t care about using OAM to audit access to the resource, and you don’t care about the WLS SSO Synchronization Filter for the resource, then (finally) you can make the resource excluded.

Short Cut Guideline
A short cut to the above guidelines that many will find useful is to designate as excluded public static resources such as images, PDF, and static html.

If such resources are grouped in directories then you can exclude them by defining policies like:

/app1/images/*

/app1/public/html/*

If such resources are more scattered, then you should be a little more careful and define resources individually or by file/content type like:

/app1/*.jpg

/app1/*.png

Conclusion

The notion of protection level for resources is an important addition to OAM 11g. The designation of excluded resources is likewise very important and will prove very useful for maximizing performance of your OAM enabled applications. You can read more about protection levels, excluded resources, and query strings in resources (which we’ll blog more about later) in the 11.1.1.5 documentation: http://download.oracle.com/docs/cd/E21764_01/doc.1111/e15478/app_domn.htm#BABJDGBB

Oracle Access Manager 11g, Oracle Forms, and a little ADF

While this post is mostly a link to an external blog, it contains good information, so I’ll be including this post in my OAM 11g Academy Series. To view the first post in the series which will be updated throughout to contain links to the entire series, click here: http://fusionsecurity.blogspot.com/2011/02/oracle-access-manager-11g-academy.html

Our friend from Europe, Olaf Heimburger, has written a couple good blog posts on integrating OAM 11g with Oracle Forms. In the 2nd post he’s thrown in a little about OAM/ADF integration (though there is more to cover on that subject).

His posts can be found here:

https://blogs.oracle.com/olaf/entry/ofm_11g_implementing_oam_sso_w
https://blogs.oracle.com/olaf/entry/ofm_11g_oam_sso_for_forms_and

Old links that no longer work for some reason:
http://blogs.oracle.com/olaf/2011/01/ofm_11g_implementing_oam_sso_w.html
http://blogs.oracle.com/olaf/2011/02/ofm_11g_oam_sso_for_forms_and.html

OAM 11g Policy Model Part 2: Application Domains and Host Identifiers

This is the 2nd post in my series going over the OAM 11g policy model and another post in the broader OAM 11g Academy series.  To view the first post on the OAM 11g policy model, as well as the index to the entire OAM 11g Academy series, click here: http://fusionsecurity.blogspot.com/2011/02/oracle-access-manager-11g-academy.html.
In this post I will go over two different but higher level constructs of the OAM 11g policy model, the Application Domain and Host Identifier.

 
Application Domains

Application Domains are high level “container” objects for lower level policy objects. They mostly represent an organizational layer in the OAM 11g policy model. Application domains contain 3 types of objects: resources, authentication policies, and authorization policies. From an abstract point of view application domains are supposed to represent all the resources and policies associated with a given application or group of applications.

Now you might be saying to yourself that since resources can only be a part of one authentication policy and one authorization policy at a time, that one could always just go with one huge policy domain containing all resources, authentication and authorization policies in existence. Well, as things stand today you’d be right.

However, there is a good chance that future OAM 11g enhancements will make more concrete use of Application Domains. I also think that it is probably a good idea to organize your OAM policies and resources by application or groups of applications. So, I encourage people to go with the flow and use application domains as they were intended to be used.

The question then becomes where does one draw the line in terms of what do we mean by application or application group? I think this is largely subjective, but that if you are creating policies for J2EE applications that it is probably a good starting point to create one application domain for every enterprise application (EAR).

Host Identifiers Overview

Host Identifiers are very similar to what they were in the OAM 10g model. They serve as a binding between hostnames or groups of hostnames and URIs. I see many people confused by the host identifier concept and so I will cover this in a lot of detail.

If you look at an HTTP request, it is composed of 4 components the protocol (HTTP), the hostname, the URI, and the query string: http://hostname/URI?queryString. For example http://www.acme.com/foo/bar.jsp?x=y

OAM policies ignore the protocol and query string components in the request and consider the resource to be the hostname + URI. Host Identifiers represent hostnames or groups of hostnames in OAM policies. The reason why OAM supports the notion of host identifier instead of just having policy authors use full URLs is because a single web resource may be accessible through any number of hostnames.

So, host identifiers are great but there is a lot of confusion out there over how to configure and use them in OAM. So, let me lay it out for you. Stay with me because there is actually a lot to cover here.

There are 3 places that host identifiers come into play in configuring OAM 11g:

  1. The configuration of host identifiers themselves.
  2. The “Host Identifier” field that you see as you go through agent registration. This becomes the “preferred host” field in the agent configuration screen. It is a little confusing but what you enter in here is not the name of the host identifier itself but the string you want the OAM server to use in resolving which host identifier to attach to the request. More on this in a bit.
  3. When you create a resource you specify a host identifier that along with the resource URL (an expression matched to the URI of the request) specifies a resource in OAM. Again, the host identifier represents one or more hostnames that a resource can be requested through.

Host Identifiers in OAM Process Flow

The request process flow of OAM 11g that is relevant to host identifiers is as follows:

1) A request comes into the web server. If the preferred host (host identifier) has been specified in the agent config for the agent intercepting the request then OAM will include the value of preferred host in the “host” field of the “is protected” call made to the OAM server to determine whether or not the request is protected and if so by what authentication scheme.

For virtual hosting support you can also specific the string SERVER_NAME on Apache based servers and HOST_HTTP_HEADER on other web servers.

On Apache based servers this will result in the agent sending down whatever Apache sets as the SERVER_NAME “environment variable”. This is generally governed by the ServerName directive of the httpd.conf or ssl.conf. For more information about ServerName and virtual hosting in Apache, see the Apache documentation on the subject.

On other servers, I believe that the HOST_HTTP_HEADER setting will send down the value of the HTTP header: HOST. However, I have not played with this yet so don’t be surprised if it actually works a little differently.

2) When the request arrives at the OAM server, OAM does a search of the configured operations (hostname + port) in each host identifier object looking for a match with what was sent down in the “host” field of the “is protected” call in step 1 above. If it finds a match it will use the host identifier the match was found in as the host identifier portion of the request as processing proceeds. If it does not find a match then it will reject the request sending back a “not protected” response to the agent, which in 11g will always cause the request to be blocked.

The important thing to understand here is that even though the documentation talks a lot about listing all the combinations of hosts and ports as you configure the host identifier and the operations are configured as hostname + port pairs, the “host” being sent down with the “is protected” call is just a string and the port being sent down is just a string.

In the case of a statically configured preferred host, this string is completely static. You can enter a preferred host of ‘purple_elephant:1234’ and in the operations of your host identifier enter host: purple_elephant port: 1234 and everything will work fine. It is also worth noting that you’ll get a match if you don’t enter a port in the preferred host while at the same time leaving the port blank in the operations hostname-port pair.

In the case of preferred host = SERVER_NAME then this string comes from the web server but is still somewhat arbitrary and doesn’t necessarily have to be the value of the HTTP HOST header.

3)  Finally, OAM goes through the process of trying to match the request to a resource in the OAM policy.  So what it does here is to go through the resource objects that have the host identifier that was identified for the request in step 2 above and tries to match the URI of the request against the resource URL in the resource object.  I’ll talk more about this matching process in a future post.

Static vs. Dynamic Preferred Hosts

The decision on whether to use a static preferred host in your agent configuration vs. a dynamic one where you use the value SERVER_NAME (for Apache) or HOST_HTTP_HEADER (for other web servers) confuses some people but is actually fairly straight forward.

For agent X, if the resource identified by any given URI /xyz is always the same, regardless of the hostname (virtual host) that the request came in on, then you can use a static preferred host.

However, if any URI designates one resource when the request comes over one host but a different resource when the request comes over a different host, then you should use a dynamic preferred host and create separate host identifiers for each virtual host being protected by that agent.

For example, let’s say agent X is running in a web server that is hosting hr.acme.com and sales.acme.com which are the hostnames for completely separate applications that both contain the URI /index.html. Then you should use a preferred host of SERVER_NAME (or HOST_HTTP_HEADER) for agent X and create host identifiers hr and sales with their respective hostnames hr.acme.com and sales.acme.com configured as operations of the respective host identifiers.

Step-By-Step Configuration of Host Identifiers

Here I will show the configuration of an agent, host identifier, and resource for both the static and dynamic models of host identification.

The following is a host identifier object configured that I used to test the static model of host identification where a static preferred host is configured in the web agent configuration. Notice how I use colored elephants as the operations without specifying a port. I did this to illustrate that we are really just working with strings here, that the agent will send down whatever is configured in the preferred host directive and that as long as this string appears in the operations of the host identifier that things will work fine.

following is the corresponding agent configuration object.  The relevant directive is preferred host.

The following is the agent object for the dynamic model of host identification.  The key here is to set the Preferred Host directive to the special value of SERVER_NAME (HOST_HTTP_HEADER on non-Apache based servers).
Then here we have the corresponding host identifier object for the dynamic model.  Note how I still have left off the port for some of the hostname/port pairs.  This is because, if you do not include a port in the ServerName directive in your Apache configuration (httpd.conf) then the agent will not send down a port.  In my example I left the port off for my HTTP virtual hosts and included the port for my HTTPS virtual hosts.
Finally, here is an image of configuring a new resource object in an OAM policy and selecting the appropriate host identifier object that we just spent all this time talking about.

 

Externalizing Authorization in PL/SQL? Inconceivable!

Ok, so it’s not a land war in Asia.But for a recent engagement, I received requirements for replacing a home-grown authorization system and doing a proof-of-concept on APEX.Eek, unsupported platform.Alright, let’s roll up our sleeves.

If there’s one thing you can find at Oracle, it’s PL/SQL expertise.I was referred to one of our rock stars, Tyler Muth, for guidance in approaching this requirement.Tyler directed me to the flex-ws-api which allows you to make PL/SQL call to a SOAP interface.OES provides a SOAP interface for authorization, so could this be love at first sight?

Flex-ws-api is pretty straightforward.You put the SOAP envelope right into the body of a CLOB data type.OES Web Service Security Module, hereto forth referred to as the Policy Decision Point or PDP, authenticates using a username-only Identity Asserter.See the OES documentation on setting up Sharepoint for instructions on this.

set serveroutput on

declare

l_BLOB BLOB;

l_CLOB CLOB;

l_envelope CLOB;

l_response_msg varchar2(32767);

l_response_xmlXMLType;

procedure show_xml (p_xml in xmltype)isl_str long;beginl_str := p_xml.extract(‘/*’).getstringval();loopexit when l_str is null;dbms_output.put_line (substr (l_str, 1, instr (l_str, chr(10)) – 1));l_str := substr (l_str, instr (l_str, chr(10)) + 1);end loop;end show_xml;

BEGIN

l_envelope := q’! <?xml version=’1.0′ encoding=’UTF-8′?>!’;

l_envelope := l_envelope || ‘ <soap:Envelope xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>

<soap:Body>

<isAccessAllowed xmlns=”http://security.bea.com/ssmws/ssm-soap-types-1.0.xsd”>

<IdentityAssertion>

<sampletoken>matt.carter </sampletoken>

</IdentityAssertion>

<RuntimeResource>

<ResourceString>app/claim </ResourceString>

<AuthorityName>ARME_RESOURCE_AUTHORITY </AuthorityName>

</RuntimeResource>

<RuntimeAction>

<ActionString>view </ActionString>

<AuthorityName>ARME_ACTION_AUTHORITY </AuthorityName>

</RuntimeAction>

<RequestedCredentialType>sampletoken </RequestedCredentialType>

<AppContext>

<Record>

<q1:RecordName xmlns=”” xmlns:q1=”http://security.bea.com/ssmws/ssm-soap-types-1.0.xsd”>attrname </q1:RecordName>

<StringValue>attrvalue </StringValue>

</Record>

</AppContext>

<AtzDirection>ALES_ONCE </AtzDirection>

</isAccessAllowed>

</soap:Body>

</soap:Envelope>’;

l_response_xml := flex_ws_api.make_request(

p_url=> ‘http://oes-pdp:9000/Authorization’,

p_action=> ‘isAccessAllowed’,

p_envelope=> l_envelope);

 

show_xml(l_response_xml);

END;

/

 

The OES response would look something like:

 

<soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>

<soapenv:Body>

<isAccessAllowedResponse xmlns=”http://security.bea.com/ssmws/ssm-soap-types-1.0.xsd”>

<AccessAllowed>true </AccessAllowed>

<AtzDecisionData>

<AtzTtlAdvice>300 </AtzTtlAdvice>

</AtzDecisionData>

<ContextRequests xsi:nil=”true”/>

</isAccessAllowedResponse>

</soapenv:Body>

</soapenv:Envelope>

From a database permissions side, the 10g database on the client site connected right to the PDP.In our 11g testing we found you had to set up some Access Control Lists on the database to have the database make a network connection.See this article for instructions on setting up this ACL.

The client was happy to PL/SQL and felt they could go the next step to externalizing this authorization in APEX.I haven’t accomplished this myself, so I would welcome readers to take this the next step.APEX has the capability for very fine-grained authorization and the ability to externalize this to a “PL/SQL Function returning a Boolean” type of Authorization Scheme, so it would seem APEX could call to OES for a Permit or Deny.

Special thanks to Tyler Muth for his direction on the PL/SQL side and Sri and the OES team for their guidance. Thanks to the A-Team for helping me get the word out.

mkc

Hands-on WSRP Security in Oracle Fusion Middleware

Introduction

This article shows how to securely propagate a user identity to a portlet, have this identity asserted and authorized to view the portlet.

WSRP (Web Services Remote Portlets) are web services. In Oracle Fusion Middleware, the way of enabling identity propagation and authentication is via OWSM (Oracle Web Services Manager) policies. The concept is no different that securing any regular web service.

Portlets authorization is handled by the OPSS (Oracle Platform Security Services) layer once authentication is done.


Note: What follows has been implemented in Oracle Fusion Middleware 11g PS1 stack (JDeveloper, WLS, Web Center, OWSM and OPSS)


OWSM policies

OWSM  is the component that implements web services security and allows for runtime enforcement and declarative policy attachment within Oracle Fusion Middleware.

OWSM provides policies for different types of use case scenarios. For example, there are policies supporting SAML token profile, kerberos, WSS1.0, SSL, etc. I will soon write an article covering OWSM in detail.

For WSRP, let’s pick a SAML token profile with WSS1.0. It basically means that the portlet will require a SAML token in the incoming SOAP header and the whole message will be digitally signed and encrypted according to WSS1.0 standards.

On the portlet producer side, we’ll attach wss10_saml_token_with_message_protection_service_policy. And on the consumer side, we’ll attach wss10_saml_token_with_message_protection_client_policy.

The policy attached to the consumer adds the SAML token to the SOAP header and performs message signing/encryption. The policy attached to the provider verifies the signature, decrypts the message, retrieve the SAML token and delegates the assertion to the OPSS layer, which verifies its validity against the configured identity store.

Securing the Producer

Authentication

The policy wss10_saml_token_with_message_protection_service_policy needs to be attached to the portlet producer. Here I will show how to do it by updating oracle-webservices.xml. Do notice this can also be accomplished via Oracle Enterprise Manager.

oracle-webservices.xml is a packaging-time artifact, meaning it is not available in JDeveloper during design-time. Therefore, to edit the file, first deploy your application to an ear file, extract the file, update it and repackage it into the ear file.

The update itself is very simple. Look for port-component name=”WSRP_v2_Markup_Service” and add the highlighted snippet shown below:

<port-component name=”WSRP_v2_Markup_Service” style=”document”
                                  bindingQName=”{urn:oasis:names:tc:wsrp:v2:bind WSRP_v2_Markup_Binding_SOAP”
                                  enabled=”true”
                                  schemaValidateInput=”false”>
   
<policy-references>
     <policy-reference enabled=”true” 
                                       uri=”oracle/wss10_saml_token_with_message_protection_service_policy”
                                       category=”security”/>
   </policy-references>

   <operations>
     …
   </operations>
   <!– start:deployment time generated info –>
   <deployment>
    <tie-class-name>oasis.names.tc.wsrp.v2.bind.runtime.WSRP_v2_Markup_Binding_SOAP_Tie</tie-class-name>
    <service-qname namespaceURI=”urn:oasis:names:tc:wsrp:v2:wsdl”
localpart=”WSRP_v2_Service”/>
    <soap-version>soap1.1</soap-version>
   </deployment>
   <!– end:deployment time generated info   –>
   <servlet-link>WSRP_v2_Markup_Service</servlet-link>
 </port-component>


Note: The portlet producer application needs to be deployed in order to be called by consumers. You cannot “Click & Run” a secured portlet application from JDeveloper.


 

Key store and Credential store configuration

This is a necessary step only because the OWSM policies we’re using require message-level protection.

Both key store and credential store are WLS domain wide artifacts and WLS expects them to be found under $DOMAIN_HOME/config/fmwconfig folder.

In a nutshell, the key store contains the signing and encryption keys used to sign/encrypt/decrypt messages. Each key and the key store itself are password protected. They are also referred by an alias. These aliases and the corresponding passwords are stored in the credential store. When access to key store is required, the credential store is first queried for the necessary aliases and passwords.


Key store contents

The key store is created by using JDK’s keytool command. Assuming JDK is on your $PATH, type keytool in a command prompt and you will see the command options.

To list the contents of the key store, type:

keytool –list –v –keystore <keystore_filename> -storepass <keystore password>


How to create a certificate key

In order to protect the symmetric key used to actually encrypt the SOAP message, we need a PKI certificate in the key store. For the sake of this example, let’s have this certificate under an alias called “orakey”, with password equals to “welcome1”.

keytool -genkeypair -keyalg RSA -alias orakey -keypass welcome1 -keystore default-keystore.jks -storepass welcome1 -validity 3600


Note: JDK 6 is required to generate a key store compatible with OWSM in FMW 11g.


 

Credential store contents

A credential store is split into maps. Each map contains a set of keys. Each key points to the actual credential. The aliases created in the key store must have a corresponding credential in the credential store. For example, if we have named our alias as “orakey” in the key store, there must be a credential named “orakey” in the credential store. Such credential is pointed by a predefined key names.

For OWSM, these key names are sign-csf-key and enc-csf-key, which are used to sign and encrypt/decrypt messages. Another important key is keystore-csf-key, which holds the key store alias and password and is used to open the key store.

OWSM uses a predefined credential map named oracle.wsm.security.


How to populate the credential store

The credential store can be populated through WLST or Oracle Enterprise Manager.

In WLST, execute these online commands:

wls:/DefaultDomain/serverConfig> createCred(map=”oracle.wsm.security”, key=”keystore-csf-key”, user=”owsm”, password=”welcome1″, desc=”Keystore key”)
wls:/DefaultDomain/serverConfig> createCred(map=”oracle.wsm.security”, key=”enc-csf-key”, user=”orakey”, password=”welcome1″, desc=”Encryption key”)
wls:/DefaultDomain/serverConfig> createCred(map=”oracle.wsm.security”, key=”sign-csf-key”, user=”orakey”, password=”welcome1″, desc=”Signing key”)

Such commands update your domain level credential store. Normally, it corresponds to cwallet.sso under $DOMAIN_HOME/config/fmwconfig.


Verifying key store and credential store configuration in jps-config.xml

Open jps-config.xml located at $DOMAIN_HOME/config/fmwconfig and check whether the following entry exists. This should be out of box configured.

<serviceInstance location=”./” provider=”credstoressp” name=”credstore”> 
  <description>File Based Credential Store Service Instance</description>
 </serviceInstance>
 <serviceInstance name=”keystore” provider=”keystore.provider” location=”./default-keystore.jks”>
   <description>Default JPS Keystore Service</description>
   <property name=”keystore.type” value=”JKS”/>
   <property name=”keystore.csf.map” value=”oracle.wsm.security”/>
   <property name=”keystore.pass.csf.key” value=”keystore-csf-key”/>
   <property name=”keystore.sig.csf.key” value=”sign-csf-key”/>
   <property name=”keystore.enc.csf.key” value=”enc-csf-key”/>
 </serviceInstance>

Also, make sure the “default” context references the key store and credential store service instances above:

<jpsContext name=”default”>
   <serviceInstanceRef ref=”credstore”/>
   <serviceInstanceRef ref=”policystore.xml”/>
   <serviceInstanceRef ref=”audit”/>
   <serviceInstanceRef ref=”idstore.ldap”/>
   <serviceInstanceRef ref=”keystore”/>
 </jpsContext>

 


Note: If this configuration is already in place, you don’t need to restart your WLS domain. Otherwise, make the changes and restart your WLS domain.


 

Authorization

Portlets authorization is delegated to OPSS layer, i.e., the decision whether or not a portlet is available to a user is done against the OPSS policy store. Portlets are just one way of exposing local ADF task flows to remote applications. There’s a component called portlet brigde that is responsible for providing the glue between portlets and task flows. It basically makes possible exposing a task flow as a portlet.

In the example below, the policy store is file-based. Normally it is represented by system-jazn-data.xml located under $DOMAIN_HOME/config/fmwconfig folder. That can be easily changed to be and LDAP-based one.

Once the right task flow permissions are already in place in the policy store, there’s only one more permission that needs to be added, and it should be granted to the authenticated-role:

<permission> 
  <class>oracle.adf.controller.security.TaskFlowPermission</class>
   <name>/WEB-INF/adfp-portlet-bridge-container.xml#adfp-portlet-bridge-container</name>
   <actions>view</actions>
 </permission>

Here’s an example of a complete set of grants required for portlet authorization. In the example, the propagated user must be granted approle1 application role in order to view the portlet (assuming /WEB-INF/my-task-flow.xml#my-task-flow is taskflow exposed as a portlet).

<jazn-policy> 
  <grant>
     <grantee>
       <principals>
         <principal>
           <class>oracle.security.jps.internal.core.principals.JpsAuthenticatedRoleImpl</class>
           <name>authenticated-role</name>
         </principal>
       </principals>
     </grantee>
     <permissions>
       <permission>
         <class>oracle.adf.controller.security.TaskFlowPermission</class>
         <name>/WEB-INF/adfp-portlet-bridge-container.xml#adfp-portlet-bridge-container</name>
         <actions>view</actions>
       </permission>
     </permissions>
   </grant>
   <grant>
     <grantee>
       <principals>
         <principal>
           <class>oracle.security.jps.service.policystore.ApplicationRole</class>
           <name>approle1</name>
         </principal>
       </principals>
     </grantee>
     <permissions>
       <permission>
         <class>oracle.adf.controller.security.TaskFlowPermission</class>
         <name>/WEB-INF/my-task-flow.xml#my-task-flow</name>
         <actions>view</actions>
       </permission>
     </permissions>
   </grant>
 </jazn-policy>

Securing the Consumer

Securing a portlet consumer basically means enabling identity propagation. This is done during portlet producer registration in JDeveloper. When doing it, make sure you select/enter the right information in step 5 at WSRP Portlet Producer Registration wizard, as shown below:


Note: the configuration made here is written to connections.xml


 

Key store and Credential store configuration

Within the portlet consumer WLS domain, both key store and credential store can be the same used by the portlet producer. Have them at $DOMAIN_HOME/config/fmwconfig, as explained previously.

It is true we have a potential security issue here, since the certificates used by WSS are the same across WLS domains, and I’ll cover how to harden it in a next article.

Identity Propagation in a flow involving OAM, OSB and web services

A Sales Consultant asked for my opinion in a scenario where a customer wants to propagate end user credentials all the way from OAM (Oracle Access Manager) to web services responsible for executing business logic.In the customer flow, after being authe…