Oracle Fusion Middleware Security

Logging in your OAM plug-in

2012-02-01T13:50:00.000-08:00

I've been playing around with the OAM plug-in API and working on putting together a very simple JDeveloper project that includes a custom login form and an OAM plug-in that demonstrates the basics of using the interface.

I'm going to get that blog post out eventually, but for right now I need to talk about logging inside your plug-in.

OAM uses the Java Logger (java.util.logging.Logger and related classes) to record all of the debugging information in an easily manageable way. When you write your first plug-in it can be a bit confusing to figure out how the heck you get your logging messages out. It's not at all complicated, but it does mean you need to understand how OAM manages its logging.

Let's start with the absolutely minimum amount of code you need to log:

package com.oracleateam.iam.oamauthnplugin;

// a bunch of imports go here

public class DemoAuthNPlugin extends AbstractAuthenticationPlugIn {
  public DemoAuthNPlugin() {
    super();
    LOGGER.finest(this.getClass.getName() + " constructor called.");
  }

  // other methods
}

That's it. The bare minimum needed to get logging working.

Of course you need to do a little more work... Click through to see what else you need to do. Read more »

A Further Introduction to Oracle IDM and Fusion Apps

2012-01-26T20:28:00.000-08:00

Last week I gave an introduction into the Fusion Middleware Security in Fusion Applications. This week I’d like to expand on that introduction to talk specifically, but still at a high level, about how the the Oracle IDM products fit in Fusion Apps. To review, here I’m talking specifically about OID, OVD, OAM, OIM, and optionally OIF.

Active Participants

If you are going to take anything away from what I have written or will write about Fusion Apps and IDM let it be this: Do not ignore the Identity and Access Management components of Fusion Applications or take them for granted.

Even more than the other FMW components in Fusion Apps, the IDM components are not black boxes. They are independent products that must be actively managed.

Independently Installed
This starts at the very beginning with the fact that unlike the other FMW components, the IDM components of Fusion Apps is installed separately from the actual Fusion Apps kit. In fact, what I like to call the IDM environment for Fusion Apps is a pre-requisite to the Fusion Apps install itself which in turn asks approximately 100,000 questions about the IDM environment that it will be leveraging. This IDM environment includes its own database and web tiers which are distinct from the Fusion Apps database and web tiers.

This process is really just a specific build out of the Oracle IDM Suite, very similar to what an Oracle IDM Suite customer might do for a traditional enterprise deployment.

So, to successfully deploy Fusion Apps, you must be able to successfully deploy the Oracle IDM suite.

Mission Critical
The IDM components of Fusion Applications are mission critical. If OVD, OID, or OAM aren’t working properly (or God forbid, aren’t working at all) then neither is Fusion Apps. It is that simple.

So, if you want a high available deployment of Fusion Apps, you better make OVD, OID, OAM, and OIM highly available.

If you want to be able to restore a backup of your Fusion Apps environment, you better know how to back the IDM components.

If you want to be able to monitor the health status of your Fusion Apps deployment, you better include the IDM components in that monitoring.

Smart people involved in the deployment and/or management of Fusion Apps will recognize this and give proper attention to deploying and tuning the IDM environment for Fusion Apps in a way that is consistent with the requirements for the total FA deployment.

Skill Sets You’ll Want to Have
During a Fusion Apps deployment and the build out of the IDM environment that is a part of that deployment you’ll want to be able to:

Understand the deployment options described in the IDM Enterprise Deployment Guide (Fusion Apps Edition).
Be able to use that guide to architect an appropriate IDM build out for your specific Fusion Apps requirements.
Be able to install OID, OVD, OAM, OIM, and optionally OIF; along with the related pre-requisite and auxiliary packages such as SOA suite, WLS, and OHS.
Be able to tune all the above components.
Be able to do basic configuration of each of the listed components. The specifics of what this means varies from component to component and even deployment to deployment.

On an ongoing basis you’ll want to be able to:

Enable and analyze debug logging for each component.
Monitor each component using Enterprise Manager (EM) or integrate the component with an existing monitoring framework in your enterprise.
Be able to take backups of the IDM environment.
Be able to start and stop each component.
Be able to patch each component.
Finally, you’ll still want to have basic configuration and administration knowledge for each component around for expected and unexpected changes and maintenance.

Conclusion
While being able to author complex OAM policies, write custom OVD adaptors, or create complex SOA composites for custom OIM approvals isn’t necessary for most if not all Fusion Apps projects; a foundational proficiency with the Oracle IDM stack where one can install, manage, and monitor each IDM product is required for a successful and stable deployment of Fusion Apps.

In the coming weeks I plan to write more about how to plan for, execute, and verify a successful IDM build out for Fusion Apps.

OIM 11g & LDAP Synchronization

2012-01-20T15:00:00.000-08:00

Since the first OIM 11g release, one of the frequently asked questions about OIM 11g is:

Should I configure OIM with LDAP synchronization or should I deploy a LDAP connector?

Since earlier versions, OIM provides connectors for the most popular LDAP systems: Oracle Internet Directory (OID), Oracle Directory Server EE (formerly Sun Java Directory/iPlanet), Novell eDirectory and Microsoft Active Directory (AD).

With OIM 11g, a new feature called LDAP synchronization was introduced. OIM uses this feature to synchronize its users and roles base to a LDAP system. This synchronization is bidirectional and it uses scheduled jobs/reconciliation engine to pull changes from LDAP and event handlers to push data to LDAP.
But if OIM already provides a connector for most of the industry LDAP servers, why provide a feature like LDAP Synch? Different customer’s business requirements, customer feedbacks and also some technical reasons led Oracle to develop this feature and make it available out-of-the-box in the product.

Read more »

Fusion Security – Apps Edition

2012-01-18T15:16:00.000-08:00

When we first started this blog more than 2 years ago, we debated about whether to name it “Fusion Security” or more specifically “Fusion Middleware Security”. We all work in the Fusion Middleware team on Fusion Middleware but even back then we saw Fusion Applications coming down the pipe and after all Fusion Apps is a set of big business applications whose principal distinction (in my opinion) is that it is the first set of business applications to be built on a truly modern middleware platform.

The much anticipated Fusion Applications was recently released. For those of you unfamiliar with Fusion Apps, it is composed of several families of applications (CRM, Financials, HR, Supply Chain, Procurement etc) that comprise the next generation version of Oracles Apps portfolio (PeopleSoft, E-Business Suite, Siebel etc.) and as I said it is built on top of most of the Fusion Middleware products that currently exist today.

Welcome Apps Community

I will start off by welcoming those in the Oracle Apps community to the Fusion Middleware community and specifically the FMW security community. The middleware products may seem complicated, even overwhelming at first, but they are good powerful products that you can build your business upon.

Why You Should Care

What does this mean for those of us in the Fusion Middleware Security community? Why should we care?

For one Fusion Apps has been driving much of the direction of Fusion Middelware for some time and now is your opportunity to see what it is all about and how the Middleware you know and love is used. In this post I’ll provide an overview of this usage and follow up with much more detail in the coming months.

Secondly, I think our community is about to get much larger. Every Fusion Apps customer will become a Fusion Middleware Security Customer. So, I’ll also take the opportunity now to say welcome to all the new Fusion Apps architects, developers, and administrators out there that may happen across this post.

Thirdly, Fusion Applications is a very large and complex set of applications. Oracle has created an Enterprise Deployment Guide specifically discussing how the Identity Management products that Fusion Apps utilizes should be deployed. It is worth reading this just to get an idea for what Oracle considers as reference architecture for an IAM environment that supports large business applications. You can find the Enterprise Deployment Guide for Oracle Identity Management (Fusion Apps Edition) here.

I myself have been very involved in the initial rollout of Fusion Applications and will continue to be very much involved along with other members of this blog in helping to advise customers on the security technology involved in Fusion Apps deployments.

What This Doesn’t Mean

With all that being said, while I do think the release of Fusion Applications is exciting and important to those of us in the Fusion Middelware Security community, I have heard some messaging around Fusion Applications and its impact on Fusion Middleware that I think oversells the importance of Fusion Apps and is ultimately incorrect.

I’ve heard it said many times that customers should closely align their use of our Fusion Middleware products to how they are used in Fusion Applications. While I agree that customers should be mindful of how FMW is used in Fusion Apps, I simply don’t agree with that statement.

Fusion Applications is a set of specific applications, namely business applications, which use our Fusion Middleware Security stack in a specific set of ways. They do not make use of every feature or even every product in our FMW Security stack. Our Fusion Middleware customers use our middleware products in a wide variety of ways, to create and support a wide variety of applications, with a wide array of business requirements, in a large variety of environments. Some of the differences between what our customers are trying to achieve with Fusion Middleware vs. what we achieved with Fusion Middlware in Fusion Apps means that customers can and should take different approaches from what was taken with Fusion Applications.

What FMW Security Is In Fusion Apps

Now that my rant is out of the way, I’ll proceed to talk about how Fusion Middleware Security is used in Fusion Applications on a product by product basis. Again, for a more detailed discussion at this time see the Enterprise Deployment Guide for IDM (FA Edition).

Oracle Internet Directory (OID) serves as the store for OPSS security policies and as the default store for Fusion Apps users.
Oracle Virtual Directory (OVD) serves as a go-between layer for user stores when OID is not being used (and optionally when OID is being used. It is also always used in conjunction with OIM for a feature called LDAP sync which provides real time synchronization of users between OIM and an LDAP directory.
Oracle Access Manager (OAM) provides authentication and singles sign-on (SSO) for Fusion Apps. It is worth noting that OAM runs in a special mode in Fusion Apps build outs and does not by default provide authorization, even course grained, for Fusion Apps. This means that some careful consideration will have to be done by customers wanting to use a single OAM deployment for Fusion Apps and other applications in their environment.
Oracle Identity Manager (OIM) helps provision users to the FA environment and provides delegated management and self service user management services to the Fusion Apps environment.
Oracle Platform Security Services (OPSS) provides the fine grained authorization for the application in Fusion Apps as well as an assortment of other functions such as LDAP connectivity and key management.
Oracle Web Services Security Manager (OWSM) provides web services security (WS-SEC) for both FA internal web services communication and the external web services interfaces to FA.
WebLogic Server serves as the core container for Fusion Apps and so WLS security is part of the picture. Specifically, identity asserters and authenticators (SSPI providers) are configured in FA. Other WLS security areas such as transport (SSL) security and node manager security also come into play.
Oracle HTTP Server (OHS) serves as the web tier for Fusion Apps. There are actually two web tiers in a Fusion Apps deployment. The first web tier is the front end to the IDM environment and the 2nd is the front end to the Fusion Apps themselves. Both web tiers will have OAM webgates on them. Beyond that SSL is the main security consideration you will have to configure / manage.
SOA Suite – SOA Suite is widely used throughout Fusion Apps including (as most of you know) its use as the workflow engine for OIM. There is a good deal of security in SOA Suite to manage including transport and message level security.

Weblogic WS-Trust Client and OWSM interoperability

2012-01-09T11:06:00.000-08:00

First, I’d like to take the opportunity to wish you all our readers a great 2012, with plenty of health, joy, care for each other and peace! We really appreciate your interest in our posts and hope to be truly contributing to your daily work. With that said…

Did you guys know Weblogic implements a WS-Trust client? Did you also know that WS-Trust client can interoperate with web services protected by OWSM policies requiring message protection (signing and encryption) ? Those were very helpful to me in satisfying some important requirements for a customer in a recent proof of concept exercise.

This is a long post. It describes a bunch of things that are more or less available across several official books, but also adds some details that are not easily found, especially if you’re interested in troubleshooting.

The customer adopts OSTS (Oracle Secure Token Service) and wanted an alternative to OWSM (Oracle Web Services Manager) client. OSTS is part of Oracle IAM Suite 11.1.1.5, delivered as an OAM (Oracle Access Manager) add-on. For an introduction to OSTS, check this post.

OSTS leverages OWSM policies to protect its WS-Trust endpoints. OWSM 11.1.1.5 also delivers WS-Trust client policies. When your web services clients can leverage the OWSM WS-Trust client policies, great, it just works. In situations where they can’t, alternate solutions need to be thought. This particular customer had a considerable amount of clients running in Weblogic server 10.3.3, where WS-Trust support is not available in the OWSM runtime. We could have looked at web services frameworks like Apache’s AXIS2 or CXF, but Weblogic’s WS-Trust client was just there, waiting to rescue. As you can see if you follow this post, it saved us quite some coding.

I must say that the approach describe here is by no means a recommended architecture for everyone. Every customer scenario is different and should be thought in light of current and future requirements. I must also say that OWSM is the strategic direction and, as such, should always be the preferred approach.

This is basically what I’ve helped the customer to achieve:

Here are the interaction details:

1) The client makes an RST (Request Secure Token) using Weblogic’s WS-Trust client to the OSTS requesting for a SAML token to be sent to the ws provider. The client identifies itself to the OSTS with username token credentials in the WSS header, but requests a token on behalf of someone else. In this example, on behalf of the client application executing user.

2) OSTS’ OWSM agent validates the WSS part of the request. It needs to decrypt the message and validate the digital signature added by Weblogic’s WS-Trust client. This is where most of interoperability problems arise. The policy attached to OSTS endpoint is oracle/wss11_username_token_with_message_protection_service_policy

3) After doing some extra validation on the RST and the requestor credentials, the OSTS issues the SAML token (RSTR – Request Secure Token Response).

4) The client calls the ws provider passing the issued SAML token along. SAML confirmation method in this case is Sender-Vouches, which means the ws client signs the SAML token. The policy attached to ws provider is oracle/wss11_saml_token_with_message_protection_service_policy.

5) The ws provider sends the response.

Implementation Details

1) Web Service Proxy

Web service JAX-WS proxy is generated for the web service provider as usual. This is done by Weblogic’s clientgen tool via an ANT build script, as shown below:

<project name="ws-client" default="build">

 <property name="wls.hostname" value="localhost"/>

Notice that you need weblogic.jar and wseeclient.jar in the CLASSPATH to run clientgen. These files are located under $MW_HOME/wlserver_10.3/server/lib folder.

You don’t generate proxies for the OSTS endpoint. This is implicitly taken care by WLS WS-Trust client.

2) Client Code

My client is a simple servlet, that actually hides some serious heavy-lifting performed by Weblogic’s WS-Trust client. The code is commented so it explains itself. Look at how simple it is.

You get an instance of the proxy port as you would normally do and add a couple of properties to the BindingProvider object in order to make the WS-Trust client invoke OSTS (lines 35-45).

1: package trunk.interop.ws;

  

import java.io.IOException;

import java.io.PrintWriter;

import javax.servlet.*;

import javax.servlet.http.*;

import javax.xml.ws.BindingProvider;

import java.util.Map;

import weblogic.wsee.message.WlMessageContext;

import weblogic.wsee.jaxrpc.WLStub;

import weblogic.wsee.security.WSEESecurityConstants;

import javax.xml.soap.SOAPConstants;

import ws.client.Greeting;

import ws.client.GreetingService;

 

public class TrustClientServlet extends HttpServlet {

 

 private static final String CONTENT_TYPE = "text/html; charset=windows-1252";

 private static final String TRUST_VERSION = "http://docs.oasis-open.org/ws-sx/ws-trust/200512";

 private static final String STS_URL = "http://dogwood.us.oracle.com:14100/sts/wss11user";

 private static final String STS_POLICY = "StsWss11UntPolicy.xml";

 public void init(ServletConfig config) throws ServletException {

   super.init(config);

 } 

 public void doGet(HttpServletRequest request, HttpServletResponse response) 

   throws ServletException, IOException {

 

  response.setContentType(CONTENT_TYPE);

  PrintWriter out = response.getWriter();

  out.println("<html>");

  out.println("<head><title>TrustClientServlet</title></head>");

  out.println("<body>");

  GreetingService service = new GreetingService();

  Greeting port = service.getGreetingPort();

  Map<String, Object> requestContext = ((BindingProvider) port).getRequestContext();

  // Oracle STS endpoint URL

  requestContext.put(WLStub.WST_STS_ENDPOINT_ON_SAML, STS_URL);

  // WS-Policy to talk to Oracle STS

  requestContext.put(WlMessageContext.WST_BOOT_STRAP_POLICY, this.getClass().getResourceAsStream(STS_POLICY));

  // WS-Trust version

  requestContext.put(WSEESecurityConstants.TRUST_VERSION, TRUST_VERSION);

  // SOAP version

  requestContext.put(WSEESecurityConstants.TRUST_SOAP_VERSION, SOAPConstants.URI_NS_SOAP_1_2_ENVELOPE);

  // username for whom a token will be requested

  requestContext.put(WSEESecurityConstants.ON_BEHALF_OF_USER, request.getRemoteUser());

  out.println(port.sayHello(request.getRemoteUser()));

  out.println("</body></html>");

  out.close();

 }

}

3) OWSM Policy in the OSTS endpoint

Line 20 defined the OSTS endpoint. If you append ?WSDL to it and paste it in a browser URL, you can see the WS-Policy generated by the OWSM policy (wss11_username_token_with_message_protection_service_policy) that protects it. It can give you very good insights in case you run into interoperability issues.

In my experience, the interoperability problems are mostly due to mismatch between security bindings, encryption method mechanisms and encryption algorithms.

Here are some typical error messages. I now know how to make them happen anytime. :-)

a) Due to security binding mismatch:

Caused by: 
oracle.wsm.security.policy.scenario.policycompliance.PolicyComplianceException: 
WSM-00059 : Signature method algorithms are mismatched. Expected : http://www.w3.org/2000/09/xmldsig#hmac-sha1, 
Actual : http://www.w3.org/2000/09/xmldsig#rsa-sha1.

In this case, make sure both policies use the same security binding. For instance, OWSM’s wss11_username_token_with_message_protection_service_policy is Symmetric. The security binding is NOT configurable in the OWSM policy.

<sp:SymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">

  <wsp:Policy>
  ...
</sp:SymmetricBinding>

b) Due to encryption reference mechanism mismatch:

[2011-09-21T16:04:27.900-07:00] [ms1] [ERROR] [WSM-00034]

[oracle.wsm.resources.security] [tid: [ACTIVE].ExecuteThread: '0' for queue: 
'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid: 
5f5492695bd28c21:-83db949:1328e2f9215:-8000-000000000000002c,0] 
[WSM_POLICY_NAME: 
oracle/wss11_saml_token_with_message_protection_service_policy] [APP: 
InteropWebServices] Error in Encryption reference mechanism compliance : 
Expected : thumbprint , Actual : ski. Ensure that a compatible policy is 
attached at the client side.

This is configurable in the OWSM policy, by changing the orasp:enc-key-ref-mech property value.

<orasp:wss11-username-with-certificates orawsp:name="WS-Security 1.1 username

with certificates" orawsp:Silent="false" orawsp:Enforced="true" 
orawsp:category="security/authentication, security/msg-protection">
 
 <orasp:username-token orasp:password-type="plaintext" 
orasp:add-nonce="false" orasp:add-created="false"/>
  
<orasp:x509-token orasp:enc-key-ref-mech="ski"/>
  
<orasp:msg-security orasp:confirm-signature="true" 
orasp:sign-then-encrypt="true" orasp:include-timestamp="true" 
orasp:encrypt-signature="false" orasp:algorithm-suite="Basic256">

c) Due to encryption algorithms mismatch:

Caused by:

oracle.wsm.security.policy.scenario.policycompliance.PolicyComplianceException: 
WSM-00030 : The encryption method key wrap algorithms do not match : Expected 
: http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p, 
Actual : http://www.w3.org/2001/04/xmlenc#rsa-1_5.

This is also configurable in the OWSM policy. In the policy snippet above, you can play with the property value of orasp:algorithm-suite and try the Algorithm Suite values as specified in the WS-SecurityPolicy specification. Make sure it matches the one in the client-side policy.

Note: In OSTS, the OWSM policies are available at $MW_HOME/Oracle_IAM1/oam/server/policy/sts-policies.jar.

4) Client-side WS-Policy for OSTS endpoint

Weblogic web service client APIs are smart enough to infer the necessary client configuration from the advertised WS-Policy in the web service WSDL. That said, we’re NOT supposed to attach any client-side policies to talk to our web service provider endpoint. However, this does NOT apply when talking to an STS using the WS-Trust client.

Notice that my client code adds StsWss11UntPolicy.xml to the BindingProvider on line 39. The xml file actually defines the WS-Policy that interoperates with OSTS endpoint protected by OWSM (once I worked through the problems showed above). Here it is:

<?xml version="1.0"?>

<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"

     xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">

 <sp:SymmetricBinding>

 <wsp:Policy>

 <sp:ProtectionToken>

 <wsp:Policy>

 <sp:X509Token 

     sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">

 <wsp:Policy>

 <sp:RequireKeyIdentifierReference/>

 <sp:WssX509V3Token11/>

 </wsp:Policy>

 </sp:X509Token>

 </wsp:Policy> 

 </sp:ProtectionToken>

 <sp:AlgorithmSuite>

 <wsp:Policy>

 <sp:Basic256Rsa15/>

 </wsp:Policy>

 </sp:AlgorithmSuite>

 <sp:Layout>

 <wsp:Policy>

 <sp:Lax/>

 </wsp:Policy>

 </sp:Layout>

 <sp:IncludeTimestamp/>

 <sp:OnlySignEntireHeadersAndBody/>

 </wsp:Policy>

 </sp:SymmetricBinding>

 <sp:SignedEncryptedSupportingTokens>

 <wsp:Policy>

 <sp:UsernameToken

 sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">

 <wsp:Policy>

 <sp:WssUsernameToken10/>

 </wsp:Policy>

 </sp:UsernameToken>

 </wsp:Policy>

 </sp:SignedEncryptedSupportingTokens>

 <sp:Wss11>

 <wsp:Policy>

 <sp:MustSupportRefKeyIdentifier/>

 <sp:MustSupportRefIssuerSerial/>

 <sp:MustSupportRefThumbprint/>

 <sp:MustSupportRefEncryptedKey/>

 <sp:RequireSignatureConfirmation/>

 </wsp:Policy>

 </sp:Wss11>

 <sp:SignedParts>

 <sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"/>

 <sp:Header Namespace="http://www.w3.org/2005/08/addressing"/>

 <sp:Body/>

 </sp:SignedParts>

 <sp:EncryptedParts>

 <sp:Body/>

 </sp:EncryptedParts>

</wsp:Policy>

5) Required Configuration in Weblogic server

I’ve been always curious on how to define credential mappings in Weblogic to be used in the context of web services. Time has come. It turns out the system properties in the Troubleshooting section (next) came up very handy to let me know the mappings to be defined.

A credential mapping essentially maps a principal to a credential to be used when talking to external systems. This is very prevalent when the external systems are based on a JCA adapter. But it applies to web services as well. For example, given authenticated user “andre” (known as the initiator) wants to call web service http://server:7003/webservices/GreetingPort from within a web service client running in Weblogic server, a credential mapping would tell which credentials the user would have to communicate with the web service.

A web service client running in Weblogic is “aware” of the security services provided by the server. In this case, given the WSS requirements stated by our 2 web services (OSTS and ws provider), two types of credential mappings are required in Weblogic:

A) 1 Default Credential Mapping:

Maps an initiator to a username/password pair. Required to add a username token to the outgoing SOAP request when calling the OSTS endpoint. A Default Credential Mapper is OOTB available in Weblogic. We DON’T need a mapping to talk to web service provider endpoint because that one requires a SAML token, which is going to be retrieved from OSTS.

Here’s the credential mapping (Security Realms –> myrealm –> Credential Mappings –> Default > New):

Protocol + Remote Host + Remote Port + Path makes up the web service URL being called. You don’t need to specify any value for Method. Notice that Path value must start with a /.

Local User is the initiator, on whose behalf the username under Remote User field is going to be retrieved. Obviously, the Remote User needs to be properly authorized in the remote system (OSTS).

B) 4 PKI Credential Mappings:

A PKI Credential Mapping maps an initiator to either a private key or a certificate. Required to perform digital signature and message encryption when calling the OSTS endpoint and web service provider endpoint. Remember, both endpoints require message protection. A PKI Credential Mapper is NOT OOTB available in Weblogic. To add one, got to Security Realms –> myrealm –> Providers –> Credential Mapping –> New (pick PKICredentialMapper). Make sure to fill in the form in the Provider Specific tab.

The keystore file Name is relative to the location where you start the Admin server. In my case, I’ve simply put clientkeystore.jks in $MW_HOME/user_projects/domains/<my-domain-name> folder.

Once you add it, restart the Admin Server so you can add the mappings (Security Realm –> myrealm –> Credential Mappings –> PKI –> New). Here are my 4 mappings:

Notice there are 2 mappings for each endpoint. One to retrieve the private key used for signing and one to retrieve the certificate used for encryption. When defining these mappings, you have the opportunity to inform the alias names in the keystore (clientkeystore.jks) holding the private key and the certificate.

6) Troubleshooting

When running into trouble, these 4 system properties will come to your rescue in the client side. Add them to EXTRA_JAVA_PROPERTIES in setDomainEnv.sh:

weblogic.xml.crypto.dsig.verbose=true
weblogic.xml.crypto.encrypt.verbose=true
weblogic.xml.crypto.keyinfo.verbose=true
weblogic.xml.crypto.wss.verbose=true

You should be able to detect, for example, why you’re not able to get a X509 token.

####<Oct 10, 2011 2:55:58 PM PDT> <Debug> <SecurityCredMap> 
<dogwood.us.oracle.com> <ms1> <[ACTIVE] ExecuteThread: '3' for 
queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> 
<> <aaa1e3e54fdb4a71:63733030:132ef6e25bc:-8000-000000000000008f> 
<1318283758414> <BEA-000000> <getCredentials: requestor=Subject: 
1
 Principal = 
weblogic.security.principal.WLSKernelIdentity("<WLS Kernel>")
, 
resource=type=<remote>, protocol=http, remoteHost=localhost, 
remotePort=9003, path=/webservices/GreetingPort, initiator=Subject: 
1
 Principal = 
weblogic.security.principal.WLSUserImpl("andre")
, 
credType=weblogic.pki.TrustedCertificate>
####<Oct 10, 2011 2:55:58 PM PDT> <Info> <> 
<dogwood.us.oracle.com> <ms1> <[ACTIVE] ExecuteThread: '3' for 
queue: 'weblogic.kernel.Default (self-tuning)'> 
<andre> <> 
<aaa1e3e54fdb4a71:63733030:132ef6e25bc:-8000-000000000000008f> 
<1318283758417> <BEA-000000> <Did not get token for token type http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3 
and purpose encrypt from token 
handlerweblogic.xml.crypto.wss11.internal.bst.BSTHandler@9527ee>

Thanks to those properties, the log message above tells it was not possible to get a X509 token for user andre to encrypt the message. Then adding a PKI Credential Mapping with the server certificate solves the problem.

And to troubleshoot OWSM, configure TRACE:32 logging level for oracle.wsm in $MW_HOME/user_projects/domains/<domain-name>/config/fmwconfig/servers/<server-name>/logging.xml:

<logger name='oracle.wsm' level='TRACE:32' useParentHandlers='false'>

 <handler name='owsm-message-handler'/>

</logger>

Log messages are sent, by default, to $MW_HOME/user_projects/domains/<domain-name>/servers/<server-name>/logs/owsm/msglogging/diagnostic.log.

Happy 2012!!

OAM 11g - UCM Integration

2011-12-20T11:00:00.000-08:00

I have been involved with many customer's who are integrating OAM 11g with Universal Content Manager 11g (UCM) and I know that trying to follow the OAM documentation can be daunting. So I put together my own integration document/Blog. Not to re-invent the wheel, this post utilizes what we already have in terms of documentation. Think of this as a checklist and the steps that I implemented to get my own internal environment working.

Prerequisites

Install and configure UCM
Install a weblogic plug-in on OHS that fixes a bug for UCM. http://www.oracle.com/technetwork/middleware/ias/downloads/wls-plugins-096117.html

High Level Steps/Checklist

Configure an OHS server to proxy all request to UCM (/cs, /adfAuthentication and /_ocsh).
Register a webgate with the URL’s you want to protect.
Configure an OAM Identity Asserter and LDAP/OVD provider in Weblogic.
Validate users can access UCM with WLS Security.
Install a webgate on OHS server and validate.

Detail Steps

Follow the documentation to configure OAM Access Manager 11g with Oracle UCM, Section 5.2.3.1: http://download.oracle.com/docs/cd/E21764_01/doc.1111/e10792/c03_security.htm#CDDHGCCC

Note: The documentation is not clear whether to install the Webgate on the OHS server first. Recommend to install the webgate at the end.

5.2.3.1 - Configuring Oracle Access Manager 11g with Oracle UCM
1.a. In our use case, we only need to protect the UCM URI’s below.

# UCM Content Server

SetHandler weblogic-handler

WebLogicHost <hostname>

WebLogicPort <portnumber>

</Location>

# UCM Content Server authentication

SetHandler weblogic-handler

WebLogicHost<hostname>

WebLogicPort <portnumber>

</Location>

#UCM online help

SetHandler weblogic-handler

WebLogicHost <hostname>

WebLogicPort <portnumber>

</Location>

b. Use the remote registration tool oamreg as follows in section 15.2.2.2:

http://download.oracle.com/docs/cd/E21764_01/core.1111/e100/osso_b_oam11g.htm#JISEC9104

15.2.2.2 - Provision with 11g Webgate
1. Acquire the tool
a. The rreg tool can be found and executed on the same box where OAM is installed. No need to un-tar.
2. Created a new UCM-Request.xml:

<serverAddress>http://ateam-hq66.us.oracle.com:7003</serverAddress>

<resource>/adfAuthentication</resource>

</protectedResourcesList>

</publicResourcesList>

</OAM11GRegRequest>

3. On the command line, execute the following:

./bin/oamreg.sh inband input/UCM-Request.xml

When asked to enter the admin and password, make sure the user is part of the system store you configured for OAM (e.g testuser1/welcome1)

2. Continuing Section 5.2.3.1
Notes:

You can configure the OAM Asserter and LDAP/OVD Authenticator before installing a webgate. Once the LDAP/OVD authenticator is configured, recommend to test UCM and make sure that you can bind to a user that is created within the provider you configured.

The order of the provider’s should be as follows:

OAM Identity Asserter
The following ‘Common’ parameters should be set as:

Leave the default values for the ‘Provider Specific’ tab.

OVD Provider
‘Common’ tab:

‘Provider Specific’ tab:

Based on the backend LDAP repository, make sure that you specify the correct object class and user name attribute within the LDAP filters. In our case, we used ‘inetorgperson’ and ‘uid’ for a user object and ‘groupofuniquenames’ and ‘uniqumembers’ for groups.

3. After Installing and configuring OAM 11g……

a. Recommend installing the webgate now. No good links in the documentation to install webgate 11g. Use the following: http://download.oracle.com/docs/cd/E21764_01/install.1111/e12002/webgate.htm#CACCBCFF

Notes:
Section 20.2.4
You will need the gcc libraries. Can get them here:
http://www.oracle.com/technetwork/middleware/ias/downloads/101401-099957.html

Look for ‘GCC Libraries for Oracle Identity Federation’

Use the following cpio file to extract the gcc libraries:
cpio -idvm <cpio-file>

Section 20.4
Step 2 - Ran the command:
./deployWebgateInstance.sh –w /u0/Oracle/Middleware11.1.1.5/Oracle_WT1/instances/instance1/config/OHS/ohs1 -oh /u0/Oracle/Middleware11.1.1.5/Oracle_OAMWebgate1

Step 3 –
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/u01/Oracle/Middleware11.1.1.5/Oracle_WT1/lib

Step 5 – Ran the command:
./EditHttpConf –w /u01/Oracle/Middleware11.1.1.5/Oracle_WT1/instances/instance1/config/OHS/.ohs1

b. Next you will need to copy the artifacts that were generated in step 3 from section 15.2.2.2. Copy the ‘ObAccessClient.xml’ and ‘cwallet.sso’ located in the ‘output/UCM-INT’ directory under ‘rreg’ to the /config directory.

Webgate installation completed. Make sure that the oam managed server is running and restart the OHS server.

Trouble shooting tips:

Cannot login via OAM – A few things to verify:

Make sure that the LDAP Authentication Module in the OAM console is pointing to the correct data store.

Make sure that the OVD provider in WLS matches the same OAM data store configuration.

In some cases we see a looping issue when using IE when the time sync of off between the webgate machine and the OAM server machine.

Logout not working
- Please follow the instructions to configure UCM logout with OAM. http://download.oracle.com/docs/cd/E17904_01/doc.1111/e14770/ucm.htm#ASRLA3579

In my next post, I will continue to integrate my OAM environment to include the Image Processing Management (IPM) tool, which requires UCM.

Multiple Identity Providers with Oracle Identity Federation and Access Manager as Service Provider

2011-12-13T06:26:00.000-08:00

Whew, that’s a mouthful for a title, but IdP N..1 SP [OIF+OAM] was probably too cryptic. Let me describe the use-case in a little more detail. Imagine if you will an education application that the state wants to surface to the various school districts. The districts want to manage user accounts and federate into the state’s application. In order to consolidate policy enforcement for both internal and external users, the state needs a single point of entry controlled by an access control system.

The documentation for Oracle Access Manager (OAM) and Oracle Identity Federation (OIF) integration on the service provider (SP) (http://docs.oracle.com/cd/E21764_01/doc.1111/e15740/oif.htm#CACJDDGE) implies that this can only be done with a single identity provider (IdP). By setting OIFScheme as the authentication scheme for the application, OAM can redirect to the service provider on OIF, which will trigger an SP-initiated Single Sign-On (SSO). There is no way to declare which IdP to use in this scenario, however. Thus, a different trigger mechanism is required for the multiple IdP scenario, plus we need to account for internal state users as well. One approach is to leverage OAM form authentication with hyperlinks to an IdP discovery page, or static links to each campus trigger for SP-initiated SSO. The format in OIF for this is http(s)://<oif>: <oif_port>/fed/sp/initiatesso?providerid=CAMPUS1&returnurl=<URL of destination app>. Once the IdP sends its SAML Response to the OIF service provider, OIF will make authentication & authorization request to OAM Policy Decision Point (PDP) based on the returnurl parameter. If successful, OIF will redirect client to the destination application with a token that the OAM Policy Enforcement Point (PEP) will honor.

One gotcha here is that the returnurl must be protected by the OIFScheme, not the form-based scheme used for internal users. That creates a challenge in that you essentially need two protected URLs for entry into the app, one to trigger the initial form authentication and one to map the external/federated users. If having all external users end up at the same portal site after authentication is acceptable, one can map the OIFScheme to a pseudoURL. You can then configure an OnAuthenticationSuccess redirect to the landing page. This pattern is only suitable if all external users come to the same page upon successful federation. I tried basing the federation policy on a query parameter, i.e. returnurl=/mysite?external=true, but OAM did not seem evaluate the query parameter, only the application context.

Another hitch is that I don’t think a 10g WebGate can consume the identity token set by the service provider. I haven’t tested to validate, but I suspect that only the 11g WebGate can consume the OAM_ID cookie. Thus, if you have a mixed environment, you will need an OHS 11g instance to handle external user traffic, while redirecting to other web servers only after an authentication cookie has been set.

5 Minutes or Less: WLS SAML2 SSO and your cookies

2011-11-30T15:20:00.000-08:00

This is somewhat related to what Brian describes in WLS Session Cookie Overriding in an OAM/SSO Enabled Environment. Here, I want to quickly point one potential issue if you plan to implement Web SSO using Weblogic server as a SAML2.0 Service Provider (SP).

When configuring a Weblogic server instance for SAML2.0 services, you have to fill in a property called “Published Site URL”.

When this instance is an SP, this property tell the partner IdP (Identity Provider) where to post SAML Responses to. In the case of SAML2.0, that URL must be http://<server>:<port>/saml2, where <server> and <port> must refer to how the IdP recognizes the SP. In other words, if you have something like a load balancer in front of Weblogic server (which is the case if you’re running a cluster), <server> and <port> would be the load balancer’s. “saml2” is the web context of Weblogic’s internal SAML2.0 servlet, whose fully qualified name is com.bea.security.saml2.servlet.SAML2Servlet.

Very well, this servlet, when called as a Service Provider, has the ability to consume a SAML assertion created by the partner IdP and instantiate an HTTP session for the browser session in the server. And it will tie it to the browser session by issuing a cookie named JSESSIONID whose cookie-path is set to “/”. So what?

It turns out that many applications specify their own cookie-path to avoid the problem of JSESSIONID clashing, where last accessed applications by the browser override the JSESSIONID cookie value during the same browser session, thus leaving orphaned HTTP sessions in the server.

It also turns out that other applications use a different cookie name to avoid the same problem.

In both cases, the JSESSIONID cookie issued by saml2 servlet won’t be accepted by the application. You may be prompted for authentication again (this time by the application), get an HTTP 401-Unauthorized error or get into an infinite loop of redirects between SP and IdP.

The most obvious solutions to these problems is removing the cookie-path constraint from the application (in which case it defaults to "/") and having the application using the JSESSIONID name. You may need to get the blessings of your application provider for supportability purposes before proceeding to the changes.

That said, get to know your applications' cookies (cookie-name and cookie-path) before integrating them into WLS SAML2 SSO.

Webcast tomorrow: Oracle Identity Analytics for Healthcare Orgs

2011-11-28T08:11:00.000-08:00

As some of you know my wife is a physician with a healthy interest in technology. So, it is somewhat exciting to us that the collision of our work world's will be discussed tomorrow as Oracle hosts a webcast discussing Identity Analytics for Healthcare organizations.

Live Healthcare IT News Webcast: Managing Risk and Enforcing Compliance in Healthcare with Identity Analytics

Featuring experts from Kaiser Permanente, PricewaterhouseCoopers and Oracle

Tuesday, November 29, 2011

10:00 a.m. PT / 1:00 p.m. ET

To find out more about this event or to register click here

More on Oracle Secure Token Services (OSTS)

2011-11-21T11:24:00.000-08:00

Last week Andre made an excellent post introducing the Oracle Secure Token Services (OSTS) product.

I wanted to follow this up by letting everyone know about a good case study on the OSTS written by Oracle's partner the PathMaker Group. The study is based on a deployement of the OSTS that they did with a customer a couple months ago.

http://www.oracle.com/us/products/middleware/identity-management/sts-wireless-telco-provider-525434.pdf

OIM 11g OID (LDAP) Groups Request-Based Provisioning with custom approval – Part II

2011-11-17T07:00:00.000-08:00

Introduction

This is Part Two of the article describing a potential implementation of Request Based LDAP Group Membership provisioning. Part One can be accessed here.

Continuing with the implementation after disabling the default approval policies at the Request and Operation Levels, the next step is to configure OIM to enable the modification of a provisioned resource via a request. The datasets associated to the Create and Modify operations of the resource in questions (OID User in this case) have to be imported into MDS. The connector’s installer at the present time doesn’t do the import of the metadata files to enable request based operations for the connector; this has to be done after installation by running the corresponding MDS utilities available in OIM.

Importing Connector’s Data Sets into MDS

The files containing the definition of the data collected by the Provisioning operations are called data sets. For OID User, there are two DataSet XML files:

ModifyResourceOID User.xml
ProvisionResourceOID User.xml

The one that we will need is the ModifyResourceOID User.xml. Here is the data set below:

From this data set this is what we will need for our implementation:

‘OID User Groups’ will be used as the attribute name to construct the RequestBeneficiaryEntityAttribute as shown in the code snippet below:

If you see any required attributes in the data set, you will have to create a value for the RequestBeneficiaryEntityAttribute for that attribute reference in the data set. The OID Server is one of those attributes. Also for the insertion of Child table records here is the specific code fragment for that:

Notice that we have to use the actual Database Table field name which can be retrieved from the Form Definition. See below:

Uploading DataSets into MDS

In this section I describe the process to upload DataSet XML files into MDS for OIM to use in Request Based Provisioning. As most of you know Data Sets determine the Fields collected during the provisioning process and certain attributes of those fields that make them required, pre-populated or only visible to the approvers. We won’t get into the details of the structure of the data sets involved here but at least we will cover a simple procedure for importing them into MDS. MDS is the acronym for Meta Data Store. Many applications part of the Fusion Middleware family rely on MDS to store configuration or Application Metadata.

This implementation works with OID’s data sets so this is the procedure to import them into MDS:

Create a directory inside // called DataSet/file (i.e in my case the directory is /opt/fmw11g/Oracle_IDM1/DataSet/file where my Middleware Home is /opt/fmw11g and my OIM installation resides under Oracle_IDM1 directory).
Copy all the datasets from the connector’s binaries home into the directory you just created in the previous step.
Switch to the bin directory inside the server directory under you OIM home directory (i.e. in my case /opt/fmw11g/Oracle_IDM1/server/bin).
Modify the file weblogic.properties inside the directory mentioned above. Here is mine:

Wls_servername is the name of the managed server as you defined it in the WebLogic Domain.
Application_name is always ‘oim’.
Metadata_from_loc is the path to the directory created in the first step. Specify this path omitting the last directory in the path (‘file’) as shown in the figure. So if you have a directory /opt/fmw11g/Oracle_IDM1/DataSet/file then the path should be specified as /opt/fmw11g/Oracle_IDM1/DataSet.

Set the OIM_ORACLE_HOME to your OIM installation Home (i.e. in my case this is what I did export OIM_ORACLE_HOME=/opt/fmw11g/Oracle_IDM1).Run the weblogicImportMetadata.bat|sh script. The script will ask the following:
User name: weblogic (Do not use xelsysadm)
Password:
Server URL: t3://myOIMHost:14000 # Provide the URL to your oim managed server and oim's port.
You should get an output similar to the one described below:

Run the script PurgeCache.bat|sh. Before running the script you need to set WL_HOME and JAVA_HOME environment variables with your location of WebLogic Server installation directory and path to a valid Java JDK/JRE directory (i.e. WL_HOME=/opt/fmw11g/wlserver_10.3 and JAVA_HOME=/opt/fmw11g/jdk160_24 coming with my FMW installation). The output should be similar to the following:

In this case the user has to be xelsysadm instead of weblogic.

Configuring the Human Task (Custom Approval Process SOA Composite)

Now it is time to look in detail at the SOA Composite that will serve as an approval process for our entitlements (LDAP Groups). Look at the following set of pictures:

From the Composite.xml design view in JDeveloper, right click on the Green Human Task icon and select Edit.

Select the Participant block and the click the Edit button at the top of the screen. This brings the screen shown below:

Notice the Value Column of the participant selection table. It is a User whose Login ID is retrieved from the payload in this case: /task:task/task:ownerUser. This is populated in the early stages of the composite right after the corresponding approver is retrieved from the Entitlements_Staging Database table for the requested Entitlement identified by the field EntitlementID. This information is retrieved by the Database Adapter Web Service configured to execute a query against the Entitlements_Staging table part of the schema defined in our solution. For information on how to configure the Database Adapter task in a BPEL process, see the documentation for Fusion Middleware – SOA Suite.

Summary

In summary this post describes a potential approach to implement Request Based OID User Group Membership provisioning using a custom approval process.

The concepts shown in this post include:

A description of OIM API’s to construct and submit requests to modify provisioned resource.
A demonstration of the process of configuring Custom Approval Processes via Request Templates.
A description of the OIM configuration required to disable the default Request and Operation level approvals.
The steps necessary to customize the SOA composite to extract required Entitlement and Associated Approver information and how to set up the Participants of the Human Task used to Approve/Reject requests.
The steps to import metadata required to enable request based provisioning for OID Resource Objects (Users and Groups).

For further details about configuration of OIM for Provisioning Processes, Process Forms, Access Policies and any details mentioned but not covered in detail in this post please access OIM Fusion Middleware Documentation from the Fusion Middleware 11g documentation.

OIM 11g OID (LDAP) Groups Request-Based Provisioning with custom approval – Part I

2011-11-16T08:32:00.000-08:00

Introduction

In recent days, I was assigned the task to implement a use case that I am sure many customers of Oracle have in mind but are not sure how to implement in OIM 11g. I even saw some thread inquiring about this very topic with no answer. Well, after some time I was able to put together an implementation of a Custom Approval process and a Custom UI based on ADF to request entitlements for users which in turn will be converted to Group memberships in OID (this also applies to any standard LDAP connector supported by OIM since the architecture is very similar for all of them). This article will be divided in 2 parts.

To give the audience a little overview this diagram shows the architecture of the solution:

As shown in the figure above, the use case is implemented by taking advantage of a very powerful feature of OIM 11g, which is the integration with SOA to execute custom composites as approval processes. Inside the custom composite an invocation to a Web Service that implements the logic to insert records on the Child Table associated with the provisioning process instance of OID User Resource Object that in turn is associated with the Beneficiary of the original request. When an administrator provisions entitlements to a given person the following sequence of steps takes place:

The WebService Data Control in the custom UI (ADF Web Application) inserts all the entitlements previously selected for this person into a Staging Table in Oracle Database.
Then an API call to UserManager service is issued to create the OIM user in OIM.
An Access Policy is evaluated against the recently created OIM user and an OID account is provisioned to the user.
Once the OID user is created a process task which is dependent on the completion of the Create User Process Task gets executed. This process task reads the records in the staging table and does one of two things:

If the entitlement doesn’t require approval, the process task directly inserts the Child Record in the UD_OID_GRP child table, which in turn causes the connector to add the group in the target system (OID in this case).
If the entitlement requires approval, the process task creates a request to modify a provisioned resource using a pre-configured request template that has Template Level approval only (Request and Operation level approvals are configured with Auto-Approval flag on). The associated approval process is our custom composite, which will be described in detail later.

For entitlements that require approval, the BPEL process part of the custom approval process retrieves the Login ID of the Approver for the requested entitlement. Then it copies the value of the approver’s login id into the task’s owner (part of the input payload).
The Human Task picks the approver from the task owner and routes the request to the approver’s queue.
The approver logs in to OIM and approves/rejects the request.
Inside the composite, the Approved block executes upon request approval and calls a Web Service that exposes a method to insert the corresponding child table record into the Child Table. This in turn triggers the adapter to add the user to the group in the target system (OID).

There are several important things to keep in mind here:

Even though the request type is MODIFYRESOURCE and the values for the child table attributes are submitted in the form, the child records are not inserted automatically after the request is approved. This has caused a lot of confusion for customers who have posted questions about how to accomplish this and no one had answered before. This is why one needs to implement the child record insertion logic and make it execute in the Approved block inside the BPEL process of the Custom Approval Process SOA composite. Later I will present such logic to you for reference.

Remember that Request Based Provisioning is not configured nor enabled out of the box in OIM 11g after connector installation. You need to import the Data Sets into MDS (This applies to any of the LDAP type connectors of OIM in 11g’s world). I will provide the steps to accomplish this later in this post.

Make sure Auto Pre-populate and Auto Save form are enabled for all provisioning processes that are automatic (OID User and OID Group).

How to do it

Now, let’s start with the procedure to make this happen. In order to implement this functionality we are going to need the following components in our solution:

Java Process Task – The purpose of this task is to read the Staging table and for each entitlement assigned to the beneficiary user’s login ID, either a request will be submitted for approval or a direct entitlement provisioning is performed immediately.
Approval Process Custom SOA Composite – This SOA composite includes the following elements:

DB Adapter Web Service that retrieves the Approver Login ID for the requested Entitlement ID/Login ID combination.
JAX-WS Web Service that inserts the Entitlement as a group in the Child Table of OID User Resource.

Custom UI based on ADF and ADF Data Controls – This user interface provides access to the following functionality:

Create Internal/External Entitlements
Assign Approvers/Sponsors to Internal/External Entitlements respectively
Create Simulation HR Accounts that will be converted into OIM users.
Run the workflow to create OIM users and initiate the process of provisioning the LDAP OID Account and subsequently provisioning the corresponding entitlements as LDAP Groups.

Request Template for Entitlements – This component links the custom approval process with the request for entitlements. The configuration of this request template is described in detail later.
Approval Policy at Request Level – This Approval Policy is used to disable the out of the box Request Level approval that will send the request to the XELSYSADM user’s queue. This policy is configured as auto approved.
Approval Policy at Operation Level – This Approval Policy is used to disable the out of the box Operation Level approval that will send the request to the XELSYSADM user’s queue. This policy is also configured for auto approval.

Java Process Task

This component is the one that does the heavy lifting when it comes to creating and submitting Modify Provisioned Resource Requests to OIM.

The figure below is the constructor of the Process Task. The parameters to the constructor allow the class to connect to the database hosting the Staging Table with the entitlements per user:

The figure shown next shows the method that obtains the entitlements for a given user and traverses the result set to submit requests for entitlements requiring approval or insert the records in OID User RO’s child table which will trigger the addition of the user into the corresponding group on the target system.

Here is the method that processes the entitlements returned by the query:

Notice the method buildBeneficiaryData presented below. This is a very important method since it actually builds the main structure of the request before submitting it.

This is the method that does direct provisioning of LDAP Groups:

The RESOURCE constant has the value of “OID User”. The RESOURCE_ATTR_NAME constant has the value of “Objects.Name”. This is to work with OID User Resource Object, if you need to work with a different LDAP Server, replace the value of this constant with the name of your LDAP Server Associated Resource Object.

For retrieving user attributes, we provide the following method:

Configure this task to be a dependant of the Create User Task of the OID User Provisioning process. That will ensure that the task only executes when the OID User has been successfully provisioned. For details on how to accomplish this, please refer to the OIM documentation part of the Fusion Middleware 11g documentation set.

Custom Approval Process (BPEL)

The requirement for this scenario is that some entitlements require approval from an Approver or a Sponsor depending on the type of entitlement being requested. Internal users request only Internal type entitlements and External users can only select External entitlements. This is enforced by the User Interface by displaying a list of selectable entitlements according to the type of user to be created in OIM. The most important elements to notice are:

The invocation task labeled as callGetEntApprover. This Task gets the Login ID of the BeneficiaryDetails and the Entitlement ID taken from the ObjectDetails parts of the inputVariable’s payload, which contains all the request data.

The invocation task labeled as call_addUserToLDAPGroup included in the block that is executed when the task gets approved. The Web Service takes two parameters: the login ID of the beneficiary and the entitlement ID of the requested entitlement. Both pieces of data come from the request data available in the inputVariable’s payload.

Disabling Request and Operation Level approvals

Out of the box, OIM has Request and Operation level approvals configured for standard requests. Both of these send an approval request to XELSYSADM and OIMINTERNAL user which are both part of the SYSTEM ADMINISTRATORS group. If this is not the desired effect, here is how to disable these approvals:

Create an Approval Policy for Request Level, the configuration from my implementation is presented below:

Now for the Operation Level approval here is the Approval Policy shown in the figure below:

Notice the value in the Scope of the policy: OID User. This is required for operation level Approval Policies. You have to select the Resource Object for which the Approval Process is defined. In my case it is the OID User but in other cases it could be iPlanet User, AD User, etc. The easiest way to do it is by Composite Name which is what I did for these two Approval Policies.

Oracle Secure Token Services 101

2011-11-15T10:46:00.001-08:00

In this post I want to introduce our readers to the Oracle Secure Token Service (OSTS) product, Oracle’s solution for providing standards-based mechanisms for trust brokerage across different identity domains. I won’t cover the gory details in this first post, but I expect to give you a good overview on what the product is, the typical usage scenarios and a basic understanding of its main concepts.

OSTS facilitates secure communications between web services providers and consumers. In OSTS terminology, a web service provider is a Relying Party, while a web service consumer is a Requester. It works as a central hub where web services consumers come and get security tokens that are further propagated to web services providers. In this way, it frees clients from all the necessary infrastructure to generate tokens required for identity propagation. Whenever the client needs a token, it requests one from OSTS.

It’s important to make clear that OSTS is no security PEP (Policy Enforcement Point) for web services. This is up to other products like OWSM (Oracle Web Services Manager) and OEG (Oracle Enterprise Gateway). It can actually be used with both of them. OEG, for example, can act as an OSTS client when protecting web services. OSTS is a set of services that validate incoming token requests and issue security tokens. It does, however, check whether a Requester can ask for a token to access a Relying Party, but it stops right there.

OSTS supports both WS-Security and WS-Trust as the protocols for token transport.

Read more »

Why do I need an Authenticator when I have an Identity Asserter?

2011-11-08T13:53:00.000-08:00

Another common question on the internal mailing list:

Why do we need an OID authenticator when I have the OAM Asserter enabled? The user has already been authenticated when the request gets to WebLogic.

The short answer is that all an Identity Asserter does is says "the request is authenticated and the username is Chris". WebLogic then needs to know how to find "Chris" and to do that it needs an Authenticator.

The longer answer is available on the net already... it's just a matter of finding it.

The old O'Reilly WebLogic book says

Identity Assertion Providers help secure access to the entry points of a WebLogic deployment. Instead of using usernames and passwords, an external client may use tokens to establish trust with a WebLogic Server. The Identity Assertion Provider verifies a token and, if successful, maps it to a valid WebLogic user. Once the token is mapped to a valid user, an Authentication Provider can then generate the principals for the user. This mechanism is called perimeter authentication, so you can consider an Identity Assertion Provider a special type of Authentication Provider. The key point here is that an external agent is responsible for authenticating the user, and then for conveying the user data to WebLogic.

Robert's Professional WebLogic Server book says

This security provider maps an outside authentication token to a username. This allows for functions like perimeter authentication. The identity asserter provides an implementation of a JAAS CallbackHandler. The default identity asserter supports WebLogic Server security tokens, X.509 certificates, CSIv2, and WS-Security password digest.

Without an Authenticator that can find the user there's no way for WebLogic to create the Subject and Principals.

I wasn't going to include this, but there is a little fine print: Identity Asserters can assert the identity without an Authenticator. These are pretty rare so let's leave that for a different post.

Provisioning Users to Google Apps in Five Minutes

2011-10-31T13:43:00.000-07:00

One exciting development (at least to me) in OIM 11.1.1.5 is the introduction of the Google Apps connector. Combine this with our existing SSO via Federation, it gives Oracle a nice lifecycle with Google Apps. Here is a quick primer on setting this up and a couple of gotchas on the docs. I wrote this a couple of months ago before the official announcement of the connector, so please correct me if there are any changes since.

There are a few 3^rd party libraries from Google required for the connector. It appears that Google has updated its libraries already from what we’ve published in the doc. If you hit the problem described in http://code.google.com/p/googleappengine/issues/detail?id=3008, you probably have a “too current” version of the Google jars.

Here’s the documentation gotcha: In section 2.2.2, there is a note that states:

“Before you run the Connector Installer, you must ensure that all third party jars must be in targetsystems-lib/googleapps-11.1.1.5.0.”

The point that is intended here is that the folder structure must match the structure of the connector that is deployed. The distribution is “Google_Apps_11.1.1.5.0”, so if you take the docs literally and don’t change the name, things won’t line up. What is happening is that OIM is packaging the necessary 3^rd party jars and importing them into the database. It’s important to get this right before installing the connector, or you get to go through a process of removing the jar from the database with scripts, repackaging, and re-importing.

Another confusing point is that the doc references the Java Connector Server. This might be a forthcoming solution, but for the time being, you can just substitute the OIM server anywhere it references the JCS. (This article didn’t have enough three letter acronyms (TLAs)).

Bottom line, what I think the packaging should be before the connector is deployed :

/Oracle_IAM1/server/ConnectorDefaultDirectory/Google_Apps_11.1.1.5.0/

/Oracle_IAM1/server/ConnectorDefaultDirectory/targetsystems-lib/Google_Apps_11.1.1.5.0/<3^rd party jars>

/Oracle_IAM1/server/lib/<3^rd party jars>

Deploying the connector from that point is standard fare. Here’s how I configured my IT Resource:

Once I assigned a resource and provisioned it, the user appeared in Google apps and I was able to SSO with that user via OIF immediately. I was also able to de-provision the user from Google by removing the resource entitlement from the user.

Samplecode is moving

2011-10-27T10:50:00.000-07:00

The Oracle Sample Code site (samplecode.oracle.com) where we've published our samples over the past few years is being decomissioned:

IMPORTANT: This site will be decommissioned on Oct. 28, 2011. Please move your projects to alternative platforms before that date.

We have already downloaded the code and will move the following projects elsewhere at some point in the future:

mutlirealm-authentication
oes-jboss
oes-spring
oes-sspi-providers
oes-ucm
opss_sample_code
owsm-11g-custom-assertions
sample-identity-asserters

If you need the code in the meantime please let us know.

Why am I seeing SIGSEGV when I strace a Java application on Linux?!

2011-10-21T11:21:00.000-07:00

A customer recently used strace on a WebLogic server that was having some trouble. The first thing that jumped out at them was hundreds of SIGSEGV, also known as Segmentation Fault, events showed up in the output. They opened a support incident and asked for more information on what might be causing all of those segmentation faults.

Most people that have used Unix for any amount of time are familiar with occasionally seeing "Segmentation Fault (core dumped)" from poorly written programs. If that's all you knew about Unix and you looked at the output of strace on a Java process you'd think something was seriously wrong ("Wow, look at all these segfaults. Those guys at Sun/Oracle must be terrible programmers and they don't know what the hell they're doing!").

The real story is quite different - SIGSEGV in a Java process is almost always perfectly normal and completely safe.

Why?

The “reassociation” business

2011-10-17T15:11:00.000-07:00

Since Fusion Middleware 11.1.1.4, OPSS (Oracle Platform Security Services) support 3 types of security stores: file, OID (Oracle Internet Directory) and Oracle database. When a Weblogic server domain is first created, OPSS is “associated” to a file-based security store by default, which is ok for development purposes. But for production, that is not recommended (Please check Multiple Nodes Servers Environments section in OPSS docs). That would be ok if your whole environment is a single Weblogic domain with only one server in a single machine. But 99,99% of the cases are not like that. Usually, an SOA or WebCenter environment is composed of multiple servers in clusters spread across different machines. A file-based security store is not a scalable option. In these cases, you should look at OID or the database. Fusion Applications, a gigantic set of apps, adopt OID as the security store.

The OPSS security store is a composite of policies, credentials, keys and audit services. Notice that I am leaving the identity store service out. OPSS delegates the identity store service to the identity providers configured in WebLogic server.

As a side note, OPSS is not a product, but a set of security services used by Fusion Middleware. If you’re a Fusion Middleware user, trying to understand OPSS is a great idea.

This post is about the nitty-gritty details of configuring (or reassociating) a Weblogic server domain (or multiple domains) to a different type of security store. That’s where the term “reassociation” comes from.

The information presented here is a small subset, but complements and sometimes overlaps “Configuring OPSS Security Store” documentation (reading is strongly recommended).
Before going any further on reassociation, let me talk a bit about an import character: jps-config.xml.

jps-config.xml

This is the OPSS file that describes all its services. It is located through the –Doracle.security.jps.config system property, which is set in setDomainEnv.sh script in a standard JRF (Java Required Files) domain. By the default, the property points to ${DOMAIN_HOME}/config/fmwconfig/jps-config.xml and it is defined in the variable EXTRA_JAVA_PROPERTIES. It is NOT a good idea to change it, since jps-config.xml holds several relative references to other files.

Read more »

OIM 11g Localization Tips

2011-10-14T13:30:00.000-07:00

As any other enterprise application, OIM 11g provides localization features: it detects user's browser language configuration and presents the UI to the end user accordingly to the configured language.
Customers can plug a lot of custom code and objects in OIM 11g in order to achieve their business requirements. While some customers don't care about localization, some of them do care, and this post gives tips on how to localize some pieces of OIM.

It is important to mention that this post does not show how to create custom fields (UDFs) or how to change request data sets.

The examples below use Brazilian Portuguese as the localization language. For other languages, check the other resource bundle files available in the exactly same folders.

Connector Request Dataset

The request data set field labels can be localized for any OIM connector deployed. The localized labels will show up when a user creates a request for that specific resource.

To localize a request data set, follow the steps below:

Edit the file $OIM_HOME/server/server/customResources/customResources_pt_BR.properties

Add the localization properties following the convention below:

request.dataset.Resource.<Resource Name>.<Attr Name>

Restart OIM Server

Notice that the property to be added to the properties file has to follow the naming convention described above. If the <Resource Name> or <Attribute Name> contains space, you must escape it like in "OID\ User".
Read more »

Virtual Users in OIF, Weblogic and OWSM

2011-10-07T18:11:00.000-07:00

One of the main strengths of SAML is the ability to communicate identity information across security domains that do not necessarily share the same user base. In other words, the authenticated user in one security domain does not necessarily exist in the target security domain providing the service.

Such concept is supported in all major Oracle products that consume SAML tokens: OIF, Weblogic Server and OWSM. The sole purpose of this post is to show how to configure it in these products. Setting up SAML services as a whole involves more than what’s showed here and I recommend the official product documentation for detailed steps.

I hope this can be helpful to someone out there.

OIF (Oracle Identity Federation)

OIF enables federated single sign on for users behind a web browser.

It calls the aforementioned concept “Transient Federation” and enables it via a checkbox (that should be unchecked) in Enterprise Manager OIF’s Console. Notice it also supports the concept of a "Mapped Federation", where the incoming identity is mapped to some generic user in the local identity store. But here I am talking about the case where there's no mapping. The user in the SAML assertion is simply trusted.

In order to enable a Transient Federation in OIF, simply make sure “Map Assertion to User Account” checkbox is unchecked in the Service Provider Common tab.

Weblogic Server

Weblogic server provides SAML services that can be leveraged by Web SSO as well web services.
Weblogic calls the concept Virtual Users and implements it in its SAML2IdentityAsserter along with the SAMLAuthenticator.

First, you need to enable your server as a SAML Service Provider. Notice this is done at the server level. Go to Environment –> servers –> <Pick server from list> to get into the screen below:

Then add a SAML2IdentityAsserter to the authentication providers list and add an Identity Provider (who does not need to be another Weblogic server) Partner to SAML2IdentityAsserter. Notice that you can add either a Web SSO partner provider or a Web service partner provider. In the case of Web SSO, Weblogic Console will ask you for the partner metadata file.

Read more »

Understanding OAM Authentication Schemes, Modules, Step Orchestration, and Plug-ins

2011-10-06T14:08:00.000-07:00

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.

I've been working on a post about plugging your own code into Oracle Access Manager (OAM) to "do" user authentication. Before I get to that post I thought it would be a good idea to explain all of stuff between when OAM collects a credential (for example a username and password entered on an HTML form) to establishing an authenticated session.

In OAM 11g the whole authentication flow from credential collection through session establishment is configurable by you the administrator, 99% of the time without needing to write a single line of code or by scripting anything. Out of the box OAM 11g ships with a bunch of sensible Authentication Schemes prewired for you which you can change or adjust to suit your needs. OAM also allows you to add additional Schemes or even upload your own code to do authentication your own special way.

To help you understand the process and terminology I'm going to start at the bottom and work my way up.

The lowest level component of the process is an Authentication Plug-in. An Authentication Plug-in encapsulates a single chunk of work, for example looking up a user based on their username, or checking the user's password against an LDAP directory.

Each plug-in does one very small thing, so you string some set of Authentication Plug-ins together to create an Authentication Module. The Authentication Module allows you to select one or more Authentication Plug-ins, each of which becomes a "Step". Then you configure Step Orchestration which is where you tell OAM which order to call those steps and what to do if each of those steps succeeds or fails.

For example the LDAP Authentication Module (the one used when you enter a username and password) has two steps:

StepUI is an abbreviation for User Identification (not User Interface!)
StepUA is an abbreviation for User Authentication.

And they are Orchestrated so that StepUI goes first and if that succeeds then StepUA follows. Here's what that looks like in the GUI:

Since a picture is worth a thousand words let's translate that into a flow chart:

OK, so what do we have so far?

A Plug-in does some work.
A Mechanism strings those Plug-ins together as steps and defines how they work together.
All that's left is a way to actually get the credentials from the user. To do that you have to define an Authentication Scheme. An Authentication Scheme has a few settings:

Name and description
Authentication Level - a number used to sort the schemes in order of most secure to least secure
Challenge method - what kind of credentials and how does OAM collect them?
Authentication Module - which authentication module is used to authenticate the credentials?
a few other scheme-specific fields

This is what the Authentication Scheme looks like for LDAP:

And that's it!

When a user tries to access something protected with this scheme they'll have to enter their username and password into an HTML form. That data goes into OAM which calls the User Identification plug-in to locate the user in the directory, then the User Authentication plug-in to check their password against the one in the directory. If both of those steps succeed then they get an authentication session (for their DN) with a level 2.

I tried to draw a picture showing the relationship between these constructs. This is the best I could do:

Did this help?

Quickly setup OpenLDAP on Oracle Linux 5

2011-09-30T08:19:00.000-07:00

Sometimes you need an LDAP directory for testing but don't need a heavy duty directory like OID, DSEE or OUD. In those cases OpenLDAP suits your needs and it's a quick and easy install.

Last night someone pinged me and asked for help doing just that. I set it up, took some notes and thought I'd share them here.

[root@dogwoodvm ~]# yum install openldap-servers
Loaded plugins: rhnplugin, security
This system is not registered with ULN.
ULN support will be disabled.
Setting up Install Process
Resolving Dependencies
--> Running transaction check

...etc...

Installed:
  openldap-servers.x86_64 0:2.3.43-12.el5_5.3                                                                                                          

Dependency Installed:
  libtool-ltdl.x86_64 0:1.5.22-7.el5_4                                                                                                                 

Complete!

You can find the config files in /etc/openldap

[root@dogwoodvm ~]# cd /etc/openldap/
[root@dogwoodvm openldap]# ls
cacerts  DB_CONFIG.example  ldap.conf  schema  slapd.conf

Make a backup of slapd.conf and then edit the original.
Duplicate these lines and then comment out one of the pair:

#suffix         "dc=my-domain,dc=com"
#rootdn         "cn=Manager,dc=my-domain,dc=com"

Then edit the duplicates you made to reflect your environment. I want the root of my directory to be "dc=oracleateam,dc=com" and the super user account needs to be inside that root. So my config looks like:

suffix          "dc=oracleateam,dc=com"
rootdn          "cn=Manager,dc=oracleateam,dc=com"

You will also need to pick and set the password for that account. A few lines later you'll see this:

# Cleartext passwords, especially for the rootdn, should
# be avoided.  See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw                secret
# rootpw                {crypt}ijFYNcSNctBYg

By default the OpenLDAP RPMs ship with the password disabled. In order to allow the administrator to connect and manage the directory contents you need to add a line like so:

rootpw          ABcd1234

If this were a real environment you wouldn't want to put the password in the clear there, but since this is just for testing it's fine. If you want to be more secure even for testing use the slappasswd account to hash the password before pasting it into the slapd.conf file.

Side note: I always use the password ABcd1234 for my test environments - it's 8 characters long, contains uppercase letters, lowercase letters and numbers. It's a weak password but it meets virtually every default password policy I've encountered.

Save the file and then start the OpenLDAP server:

[root@dogwoodvm openldap]# service ldap start
Checking configuration files for slapd:  config file testing succeeded
                                                           [  OK  ]
Starting slapd:                                            [  OK  ]

If you want the OpenLDAP server to start automatically on boot use chkconfig to do that:

[root@dogwoodvm openldap]# chkconfig --level 35 ldap on
[root@dogwoodvm openldap]# chkconfig --list ldap
ldap                0:off     1:off     2:off     3:on     4:off     5:on     6:off

Once you've done that you need to actually create the directory root objects inside the directory. To do that you can use a graphical LDAP editor or just use the command line ldapmodify tool.

[root@dogwoodvm openldap]# yum install openldap-clients
Loaded plugins: rhnplugin, security
This system is not registered with ULN.
ULN support will be disabled.
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package openldap-clients.x86_64 0:2.3.43-12.el5_5.3 set to be updated
--> Finished Dependency Resolution
... etc ...
Installed:
  openldap-clients.x86_64 0:2.3.43-12.el5_5.3                                                                                                          

Complete!

Then use ldapmodify to create the entries.
Run the command:

[root@dogwoodvm openldap]# ldapmodify -D 'cn=Manager,dc=oracleateam,dc=com' -w ABcd1234 -x

Then paste the entry in

dn: dc=oracleateam,dc=com
changetype: add
objectClass: dcObject
objectClass: organizationalUnit
dc: oracleateam
ou: rootobject
description: LDAP Admin

and hit return to leave a blank line. The command should come back and tell you that it's adding an entry, like so:

adding new entry "dc=oracleateam,dc=com"

Then create the Organizational Units (ou) for People and Groups if you want them by pasting these in and hitting return after:

dn: ou=People, dc=oracleateam,dc=com
changetype: add
objectClass: organizationalUnit
ou: People
description: Users

dn: ou=Groups, dc=oracleateam,dc=com
changetype: add
objectClass: organizationalUnit
ou: Groups
description: Groups

Hit ctrl-d to exit and you're done.

OIM 11g Event Handler example

2011-09-28T14:45:00.000-07:00

This post shows an example of a post process event handler in OIM. The example is simple and it shows how the user profile can be updated from the event handler based on the information that is provided by OIM to the event handler.

Use case description: a UDF is created in the user profile and it will hold the user's 'Director'. To simplify the use case, the 'Director' will be the 'manager's manager'. In other words, the UDF will be populated with the information from two levels up in the management chain, the value to be used is the director's login.

The first step is to create the UDF that will hold the data. An authorization policy is also needed, otherwise it will not be possible to update the UDF using the APIs. All the steps below must be done in OIM logged as system administrator.

Creating the UDF:

5 minutes or less: User/Role API and SSL

2011-09-23T14:57:00.001-07:00

This short post follows up Couple of things you need to know about the User/Role API. Now imagine that your LDAP identity provider is SSL enabled in 1-way mode (the server authenticates to the client, but the client does not authenticate to the server).

Now you need to tell Weblogic server how to validate the LDAP server certificate. And this is accomplished by adding the LDAP server CA certificate to the configured Weblogic trust store. If we’re talking about a self-signed certificate, simply add the certificate itself to the trust store. And there are a couple of options for the trust key store: Command Line, Custom Trust, Java Standard Trust or the OOTB Demo Trust. So far, so good. By adding the certificate to one of these options, Weblogic is all good to talk to the identity provider in SSL mode.

However, the User/Role API is not directly tied to Weblogic, so don’t expect it to take whatever is configured for the server. By default, as a standard Java-based client, the User/Role API looks for the standard Java $JDK_HOME/jre/lib/security/cacerts file, unless you tell it to look elsewhere, by informing the java system properties

javax.net.ssl.trustStore=<path_to_trust_store_file>
javax.net.ssl.trustStorePassword=<trust_store_password>

Relying on the original cacerts file may be dangerous in case you upgrade your JDK. If you need to leverage the existing certificates there, make a copy of the file and use the copy. Then simply tell the User/Role API where to read it from using the properties mentioned above.

Five Minutes or less: OpenID

2011-09-22T11:10:00.000-07:00

Most of the technical people I work with know what SAML is and how it works and how the federation protocols for SAML work (SP initiated, IdP initiated, Browser Artifact, Browser POST). OpenID is much less well known.

So here's what you need to know about OpenID in five minutes or less.

In OpenID there are three parties:

The user and their browser.
The Relying Party (sometimes abbreviated to RP) is the web site that's asking the user to authenticate. In SAML this is the Service Provider.
The OpenID Provider (sometimes abbreviated OP) is the web site that's going to vouch for the user. In SAML this is the Identity Provider

Many people use the SAML and OpenID terms interchangeably when talking about the OpenID parties but I'll try to remember to stick with the right ones for this post.

OpenID works a whole lot like SAML's SP Initiated Browser POST authentication except for these differences:

All user interactions are via HTTP GET
The RP and OP communicate directly with each other via HTTP

Here's a simplified view of the flow:

I've broken the flow into three stages:

Choose OP
Login @OP
AuthN

Note: these are my own divisions and names; the OpenID standard doesn't break the flow up and doesn't have names for what I call stages.

Stage 1: Choose OP
The first step in the OpenID flow is the user telling the Relying Party which OpenID Provider they would like to use, often though the NASCAR style row of buttons. Under the covers each of those buttons corresponds to a URL and when you click the button the HTML form is actually submitting the URL to the Relying Party's web site. In some cases the site will allow you to enter a URL of your choosing.

When you send the URL to the site the Relying Party checks to see if it "likes" the OpenID Provider (usually by checking against a list of providers). If the URL looks OK the RP makes an special HTTP request, called an XRDS request, to the OP. The OP returns back a bunch of data describing the OP including the features and functionality that the OP offers.

A couple of other things happen here, but in the interest of time I'm going to skip over them.

If everything looks OK the RP redirects the user to the OP with an Authentication Request (via an HTTP GET with the data in the query string).

Stage 2: Login @ OP
When the user sends their Authentication Request to the OP the OP makes the user login. If the user has already logged in to the OP then that step might be skipped.

After the user has authenticated to the OP the OP generates an authentication response for the RP and redirects the user back to the RP.

Stage 3: AuthN
Finally... the user presents that authentication response to the RP (via an HTTP GET). The RP checks it out and if it's "good" then the user is considered logged in.

Finally the RP returns the content, application or whatever it is that they were trying to do at the RP in the first place.