Part 1: Getting under the covers of Detached Credential Collector (DCC)

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. The Detached Credential Collector (DCC) feature was introduced with the release of OAM 11gR2 --- 11.1.2.0.0.   DCC brought some very interesting changes in the authentication model that in my opinion are very welcome; more on that later.  There is already Oracle documentation out there on this feature, along with an A-Team blog article Debasish Bhattacharya created (Detached Credential Collector Configuration – OAM 11GR2) , which adds some more insight on configuring DCC.  This blog is to enlighten everyone with some more information on what is going on with DCC, both for login and logout.  Then in Part 2 – Custom Login and Logout with Detached Credential Collector, I want to clear up some confusion on how many may think using DCC can only be done with the Oracle supplied login.pl and logout.pl Perl scripts; that is far from the truth.   So let’s dig in and expose some of the mysteries of the Detached Credential Collector.

 Main Article

About DCC (Detached Credential Collector)

As I mentioned in the introduction, Detached Credential Collector is a capability that came with the release of OAM 11gR2 (11.1.2.0.0), and note this is for 11g WebGates only.  If you login to the OAM Console and look at an 11g WebGate profile you will see the checkbox option “Allow Credential Collector Operations”.  See the graphic below that highlights the option.  This checkbox is the only difference that makes a DCC WebGate what it is from a configuration standpoint.

The term Detached Credential Collector (AKA Authenticating WebGate), relates more to the way credentials are collected when submitting the login.  For example with DCC the login credentials are collected at the DCC WebGate versus ECC (Embedded Credential Collector) where the credentials are collected directly by the OAM Server.  This is a key difference between DCC and ECC, which greatly changes the authentication model.

How the DCC and ECC Authentication Model differ?

The Oracle documentation Administrator's Guide for Oracle Access Management 11g Release 2 (11.1.2) in section 16.5.2 Comparing Embedded Credential Collector with Detached Credential Collector has a very nice table comparing DCC to ECC.  If you compare each row side by side you will find that DCC compares pretty much the same as ECC, but one big difference is the method of where the credentials are collected, as I mentioned earlier.  I like to use illustrations to explain something because I think it helps make a complicated subject easier to understand.  Just keep in mind the diagram is very simplified, so there are certainly other request and response trips between the WebGates and OAM Servers, but I really wanted to keep it high level to capture the essence of DCC vs ECC authentication model.

The diagram above is trying to illustrate at a high level the differences between the DCC and ECC authentication model.  The DCC flow is in blue and you can see in sequence 2 the User submits their login credentials directly to the DCC WebGate.  In the ECC model the User submits the credentials to the OAM Server, which is located in the mid tier --- very interesting. So the big “Ah Ha” moment here is that the DCC model completely separates the client from the OAM Servers in the Mid Tier, a model which many consider to be more secure!    Particularly for internet-facing deployments of OAM, where the ECC-model requirement to allow HTTP access to the OAM server (for credential submission) can present challenges in terms of ensuring adequate security. There are, of course, ways to mitigate security concerns in the ECC model such as a firewall and or a load balancer to setup rules to prevent any malicious traffic being sent directly to the OAM Servers.  This is security 101 that should be incorporated into a good architecture anyway; doing it for the OAM Servers using ECC should be done by default.  In addition, OAM already has built in features to help mitigate things like buffer overflows and such, so don’t be too alarmed. That said, you can see how much simpler security could be using the DCC model.  DCC makes security a little less complicated by separating the WebGates in the Web Tier from the OAM Servers all together.  In a way the DCC model is similar to the old OAM 10g model where your login credentials are submitted directly to the WebGate, and the WebGate communicates back to the OAM Servers over OAP which mitigates any chance that a rogue user will send direct requests to the OAM Servers in the mid tier.  So DCC is something to really consider.  In my opinion this is a very welcome feature of DCC.

Let’s look at some HTTP Traces

I like to start by capturing some HTTP traces to see what is going on, so let’s dive down a couple layers and see what is going on.  Before I do, I first want to point out that for the DCC HTTP Traces I am presenting I used the out of the box login.pl and logout.pl scripts.  However I want to let you know that it is completely possible – and perhaps even advisable – to replace these scripts with custom functionality.  So for illustration and to build on Debasish Bhattacharya’s Detached Credential Collector Configuration – OAM 11GR2  blog I wanted to start by keeping things simple; in Part 2 I will expand in more detail on how to create a custom login and logout which does not use the Perl scripts and includes very important information needed to make it all work perfectly. Below is a sequence diagram that shows a flow of a user logging into the Acme Portal, but also requesting a second completely different domain (Globex Portal) where the user is not challenged again because of SSO, and finally the logout of all domains.   I will try to keep this interesting, but then in Part 2 I will go further to show all the details for a custom login and logout.

SEQ 1 - Initial HTTP Request

Sequence 1 shows that the initial request is to http://acme.melander.us/.  This sequence is pretty normal and looks exactly the same for ECC.  Below you can see the GET to acme.melander.us, but in sequence 2 things change a bit and start to differ between DCC and ECC. GET / HTTP/1.1 Host: acme.melander.us Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8



SEQ 2 - Redirect to DCC Login Response

In sequence 2 the Resource WebGate realizes the browser does not have an OAMAuthnCookie SSO token so then tells it to do a HTTP 302 and redirects it to the DCC WebGate web server.  In the HTTP trace below it shows a HTTP 302 along with the obrareq.cgi, which is really no different than what is seen in an ECC HTTP Trace. HTTP/1.1 302 Found Connection: Keep-Alive Content-Length: 595 Content-Type: text/html; charset=iso-8859-1 Date: Fri, 12 Sep 2014 12:03:59 GMT Keep-Alive: timeout=5, max=100 Location: http://sso.melander.us/obrareq.cgi?encquery%3DShtPLKTcR3ddwuuVUNKCo8d1wy5tSOb7qqKXkir9P40L6lyHvskOs%2FzhPfjjuTJ2f43Dj7tU2NDKk27tII2zKcEznG%2FiojLgapQxWTrH5yxVNo9Dusv6sHSQdkHasWnyX6W5TAeoS7Hvp6ViajGsusRxEClG%2BuDJWEmPz%2BkUYwDHcdFFXFcy98QlU37r6EL3NS0IAPqSY%2FUVaFRdpflMLO2YTjbLKFmHN2KbanzgMfLiG716VxGMEXTFNJsMdkdyrle%2BF1Q155cDfRVQKk4qCg%3D%3D%20agentid%3DACME%20ver%3D1%20crmethod%3D2 Server: Oracle-Application-Server-11g Set-Cookie: OAMAuthnHintCookie=0@1410523439; httponly; path=/; domain=.melander.us Set-Cookie: OAMRequestContext_acme.melander.us:80_696f34=io4lVtGlkrIosz2NHpKjEA==;max-age=300; httponly; path=/ The main reason for the redirect to the DCC WebGate is because the authentication scheme is configured for DCC.  Refer to the graphic below that shows side-by-side screenshots of a DCC authentication scheme (On the Left), and an ECC Authentication Scheme (Default LDAPScheme On the Right).  Notice the differences between the Challenge Redirect URL and Challenge URL?  In the DCC Authentication scheme the Challenge Redirect URL points to the hostname where the DCC WebGate is located which could also be a Virtual hostname for a Load Balancer.  The Challenge URL for the DCCAuthnScheme points to the location of the out-of-the-box login.pl.

SEQ 3 – Set DCCCtxCookie and redirect to login page

In sequence 3 this is where things get a little more interesting.  In the HTTP trace a new type of cookie is created, this is the DCCCtxCookie cookie.  In my trace the DCCCtxCookie is set for the sso.melander.us domain; the DCC WebGate host configured in the DCC Authentication Scheme.   The DCC WebGate looks for a DCCCtxCookie and if not present will generate one.  The DCCCtxCookie is basically used by the DCC WebGate to save context information during authentication.   More details on this cookie can be found in section 15.6.2.5 DCCCtxCookie of the OAM Administration Guide 11gR2 release.   Something else that shows up in the HTTP trace is a resource_url query string parameter that contains the last requested URL. This lets the DCC WebGate know where to redirect the browser after successful authentication. HTTP/1.1 302 Found Connection: Keep-Alive Content-Length: 277 Content-Type: text/html; charset=iso-8859-1 Date: Fri, 12 Sep 2014 12:03:18 GMT Keep-Alive: timeout=5, max=100 Location: /oamsso-bin/login.pl?resource_url=http%3A%2F%2Facme.melander.us%2F Server: Oracle-Application-Server-11g Set-Cookie: DCCCtxCookie_sso.melander.us:80=encdata%3DEKHXNSVKumgJQBImv1RLbxh8kT8E23bIKJeEmH87GvOrWLXD6YLv8adLGuGA%2FymjsB03bbu45t3%2FBJl17Xc5nBAHAsGt%2BoFbzTwwNRXvMI2TyAiKYFPI3gDXKjeA9SabxjC2UpDJe0DQ6yD0xwaezuoDZiLUbrMKe6B0otlfjvayuxK0yqDReA8F3pE6nNElH2Ln31hKt1W2dHKI%2BPzEJW8bdcYzCNLZ%2BPxGBTj%2FdN6E8uV32Yp8C%2BZemDusLFpFt6RhQdQheZUFRTyvYKPsralO3UGmFPW9T7r5Weo3nxU%3D; httponly; path=/oam/server/auth_cred_submit

SEQ 4 – Submit Credentials

This sequence is where the login page submits the username and password.  There are some very important points to know here.

1. 1) In this example my authentication scheme is very simple; I only require a username and password.  In the POST you would see the username and password input fields along with the actual values.  Normally using ECC you would also post the OAM_REQ or request_id.  However if the DCC Authentication Scheme was setup to do multi step authentication, the OAM_REQ would actually show up and it would also be required at the time of posting the credentails.
2. 2) Notice that the credentials are directly posted at the DCC WebGate host? This is quite different than ECC where the post is sent directly to the OAM Servers. The DCC WebGate becomes the credential collector; hence the name Detached Credential Collector. Also notice that the URI that is posted is /oam/server/auth_cred_submit, which is the same as ECC – the major difference is that this URI is served to the DCC WebGate, rather than the OAM Server.

HTTP/1.1 200 OK Cache-Control: no-cache, no-store Connection: Keep-Alive Content-Language: en Content-Type: text/html; charset=UTF-8 Date: Fri, 12 Sep 2014 12:03:18 GMT Expires: 0 Generated-By: login.pl Keep-Alive: timeout=5, max=99 Pragma: no-cache Server: Oracle-Application-Server-11g Transfer-Encoding: chunked POST /oam/server/auth_cred_submit HTTP/1.1 Host: sso.melander.us Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Encoding: gzip,deflate Accept-Language: en-US,en;q=0.8 Content-Type: application/x-www-form-urlencoded Cookie: DCCCtxCookie_sso.melander.us:80=encdata%3DEKHXNSVKumgJQBImv1RLbxh8kT8E23bIKJeEmH87GvOrWLXD6YLv8adLGuGA%2FymjsB03bbu45t3%2FBJl17Xc5nBAHAsGt%2BoFbzTwwNRXvMI2TyAiKYFPI3gDXKjeA9SabxjC2UpDJe0DQ6yD0xwaezuoDZiLUbrMKe6B0otlfjvayuxK0yqDReA8F3pE6nNElH2Ln31hKt1W2dHKI%2BPzEJW8bdcYzCNLZ%2BPxGBTj%2FdN6E8uV32Yp8C%2BZemDusLFpFt6RhQdQheZUFRTyvYKPsralO3UGmFPW9T7r5Weo3nxU%3D; OAMAuthnHintCookie=0@1410523439 Origin: http://sso.melander.us

SEQ 5 & 6 – OAM Server evaluates the Credentials

In these two sequences the DCC WebGate sends the credentials to the OAM Server over OAP on port 5575 and you can see in the following OAM diagnostic trace log the authentication is successful.  The success is sent back to the DCC WebGate so it can continue to finish setting the next cookie and redirecting the browser back to its original requested URL. [2014-09-12T12:04:00.488-04:00] [oam_server1] [TRACE] [OAMSSA-20097] [oracle.oam.user.identity.provider] [tid: [ACTIVE].ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid: 4228756130348ab3:7de41016:1487a914541:-8000-0000000000003cd0,0] [APP: oam_server#11.1.2.0.0] [SRC_CLASS: oracle.security.am.engines.common.identity.provider.impl.ids.IDSUserProviderImpl] [SRC_METHOD: authenticateUserByName] User abarnes in idstore OUDIdStore authenticated successfully



 SEQ 7 – Now Redirect back and include the Session Token

In this sequence the DCC WebGate sends a HTTP 302 back to the originally requested URL, http://acme.melander.us, but also notice it includes the obrar.cgi?encreply= value.  The obrar.cgi contains the encrypted session token which we will need when we get back to the acme.melander.us Resource WebGate. HTTP/1.1 302 Found Connection: Keep-Alive Content-Length: 1194 Content-Type: text/html; charset=iso-8859-1 Date: Fri, 12 Sep 2014 12:03:21 GMT Keep-Alive: timeout=5, max=98 Location: http://acme.melander.us/obrar.cgi?encreply=n8OSU11hQvFoB44j/eb8hUbwsopUla62fbjmZtMP8J+fSQTJsyOLfHZnSjul4Z+kj08e5xiYARwuk4RwtIW7Hbj5/SgeUoPo62EtEiKLgmE76OQUFo3hRzSdhwG0w/fEAvLOSSjMrn7CB/hIIips27FksoQTbIrtt1aQ54mFsXRrViQSleRlQcVhHFCMo5nDhljHEH/IYVkaXzFEB8PwkoosKs7G7doqSlFgubxAYYID+6ZfxyLYpzWbNsRLBgMWqMe6pKnDQ2Bq1jPHdy1F6Ye8gMdfSzKHKVfeY2Y9RnBmV+jEeAS2yDevuIOP3/18jTAcfHYtS7rZvaZApFb3AYrwWNGeL1aY7SxLvEZWK7kdIZfqifwxjWZHHp9PMIQ2KfmR5ij9ovi8W+k72TN9uJDLZV/iWvJHiRKR84HMGjjj/QwNkgygtxslILimy8Qqfcpt5lECT3nbdTTsF82hzZnxCvCA1cP3SaVHjR8dQCiS4np1rr//bxgyAwX7gxnLJt7OBB9QbUcasfOoH1uIp5zcPYamTyIrqX64YEzXtGk2eIJl6KWbeV7xsWbs31U4B09HawJa420hveUO0wKdEmTKMZIYBggsRHN7rVyovIUf6fp/rat8n2rqsdb5nlLAAEI7GxfXi0G206iEK+7vZ1inioY9YPLa+TocaGJe7/fgDGkk3Wsxj6cidIAyRVLi5Dy2OdZ6tSKfpaH6Y7iJptFKrdkoRGoeELYOANIzSRyW/wi+9C/DIvwypgnHfuv5/BpPAEnm2jHBwkS4ZPQFNw00t2H4nxv1x115j6ToDa0PJaqwsUwOFUE4GCyGshD/42BlqF3Ycnbsgeie5VJ2xNCMg+p2h3gwD9tExJCa1jNo3dn7h2yAKLTMq4vc7MyOUMfCjDDu3JILOM3epT51OFkGRRqAyfx/vZbHdbLe1CM= Server: Oracle-Application-Server-11g Set-Cookie: OAMAuthnCookie_sso.melander.us:80=XiuQpggJbUzLaMtekqbd8HH6jtIcoNDmrzCkMBO0pf6SN3I1Pfnh8kfkzDAV3CHAMvcfjBZmAZLcef1G5tmTk51Nv664AO4mxKR9SCk07nCMPZdnUkZJldEL%2FP3N%2B18Ms3pZS%2Bm9kERpFCbBKCJf19%2FXjXWf%2B5VyLFOO3P88pHD6Rwcklfbcw6s2Oq5RR32UFZcpfVS79EWv8wocT4isczlTv5QkAVF0SpDocuEzhPE52GAxOSz%2Fjew5Q2pStKCF%2BA%2ByMR2pD2I3JFqAmt%2BZvxWlInEwOCCAC2RzMQzjPKvgy3EFv5iFLkd0ym1pXbkwR115I0lGQhRC9QM2vrQOyMd2Fmpmn%2BUpi9iT7juia0W5iJfd7MrpJPtebbNfBkTTnFJxGw5yVcecEOLPrGj1ubsNhtsKHwsP%2Bh18D4F6FsW2GoUx95X4NpxtG4MoORaYYGODr7roS7axEZSqBJzNRYBPZEMlPfz%2BQDxy3MicS6A%3D; httponly; path=/ Set-Cookie: DCCCtxCookie_sso.melander.us:80=;expires=thursday, 01-jan-1970 01:00:00 gmt; httponly; path=/



SEQ 8 – Set the OAMAuthnCookie for acme.melander.us

In this sequence the Resource WebGate for acme.melander.us gets the session token and then sets the OAMAuthnCookie for the acme.melander.us domain.  We now finally have SSO and the WebGate then grants the access to the content served up by the application server in sequence 9. HTTP/1.1 302 Found Connection: Keep-Alive Content-Length: 212 Content-Type: text/html; charset=iso-8859-1 Date: Fri, 12 Sep 2014 12:04:02 GMT Keep-Alive: timeout=5, max=99 Location: / Server: Oracle-Application-Server-11g Set-Cookie: OAMRequestContext_acme.melander.us:80_696f34=;expires=thursday, 01-jan-1970 01:00:00 gmt; httponly; path=/ Set-Cookie: OAMAuthnCookie_acme.melander.us:80=KeXCJKNeD4%2BKHMDKkBVFYrsZ94DcSb4JAbxuaCaUuvwoBDm3ljelAGlA30YsNi30IBGq4o8oRsTsTHkgity88Fl%2BvmSXHKCIhV5Ud0kyb3yErIWjjymaUWlbktnDhZaxvsq3we9viOESHKPCz6TZblUmLgnLbRxBLZmH0QvS32S5NexWSylBKlcHDBPOr78irmnE2S1Q1Bpp%2FmaFk6X3oE%2FP8LNRe0FVN4h7HNLz7q%2FUERIQbsulch8dsFdl2z97xWrz2PsUifvtlF5jG72xWLyaZbnRE8ERWxkotWD8wyDQha7xaBXIhWpOBnR5O5nRCvUUyzRTxE%2FnrNQRPucF%2F%2F9P2NaEazAEXWfAzf1cWKQ8GC1gjG%2BzN7E0BroGEPwaQ4EOI66mSbAA%2BVJ7QWvkIQt%2F7FHSbQGHFizqjC%2FJiueFRU6mFsO%2FwYUQ%2B6TeYzqoXZ03Xe%2F07ru5%2BBrdGbRzFoitRFCSwrFMtP0O5wm%2BGZQ%3D; httponly; path=/  

Keep that Session Going with Multi-Domain SSO

Let's keep going using the SSO Session and try to request globex.idfocus.com, which also is using the same DCC Authentication Scheme.  So using the same sequence diagram we can continue our learning.

SEQ 10 – Request globex.idfocus.com application

Much like sequence 1, this sequence is just a GET for the globex.idfocus.com.  No frills or thrills in the HTTP trace below, just as expected. GET / HTTP/1.1 Host: globex.idfocus.com Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8



SEQ 11 – Encrypt and send the session token to the DCC WebGate

In this sequence something familiar happens just like in any multi-domain SSO configuration with OAM.  The Resource WebGate for domain globex.idfocus.com does not have a valid session yet to satisfy authentication, so similar to sequence 2 it redirects the browser back to the DCC WebGate at sso.melander.us for authentication and includes the original requested URL and some other information encrypted in the encquery parameter value as seen below in the HTTP trace. HTTP/1.1 302 Found Connection: Keep-Alive Content-Length: 623 Content-Type: text/html; charset=iso-8859-1 Date: Fri, 12 Sep 2014 12:04:05 GMT Keep-Alive: timeout=5, max=100 Location: http://sso.melander.us/obrareq.cgi?encquery%3DR9T1bzgn2ARi3h9h6fS4x0brZ2JTAeoaEy7uzqo5YA%2FGai0y%2B4xpJ%2B1%2BoqVxziO1YZ2jFd9IHLeEBmJkasL5GG4Yw1B%2FIzR%2Fzahx4FV3pbntKMYL%2BdfHxsIgrf1MCUTwrMsL8zuzmXUgj6SwuzeFOF606C6SlNoGehhgXnRhD88zvXnMsdnvCnaGy7Q%2F8W5SNQf8QHt9zN2wzMVhQn%2BGvGexLAwclWZthZbKgpUbMsnQ5tpTTtua%2B0dYt2XuhYn5q09ihY3gozRoTGyTY3riS7DzjMPiwr9TK4SMgdMJv6U%3D%20agentid%3DGLOBEX%20ver%3D1%20crmethod%3D2 Server: Oracle-Application-Server-11g Set-Cookie: OAMAuthnHintCookie=0@1410523445; httponly; path=/; domain=.idfocus.com Set-Cookie: OAMRequestContext_globex.idfocus.com:80_783376=x3vA+i4lAGQmfHXaX0XW6A==;max-age=300; httponly; path=/



SEQ 12 – Encrypt and Send the Session Token back to globex.idfocus.com

In sequence 11 we saw some encrypted data and now the DCC WebGate intercepts it and determines that needs to now encrypt the token in the obrar.cgi encreply parameter string, which is basically the authentication response from the 11g WebGate. HTTP/1.1 302 Found Connection: Keep-Alive Content-Length: 1202 Content-Type: text/html; charset=iso-8859-1 Date: Fri, 12 Sep 2014 12:03:24 GMT Keep-Alive: timeout=5, max=97 Location: http://globex.idfocus.com/obrar.cgi?encreply=vQrCrUuQgsRYwGM3ttT22vAsZ6S1aYVO2oqKEgmd+WDJV8heYYJ8BSWMFxYarlUE+ku2+dFzgoTka6YFkTN7k2Cksc7jbL/WPOJSH9kv15y/HrJ2TUeQZzsvxKgQ+QbTpQLWqA4RuUAssgF3BhSvpeE9SNYTIdmMWl7cnk2iykuH2nwqbfmHTeFnazby8ueaNghwSMabgaLQWQCGwkYQc1WFOGa46SPPJHH6mmf1RUZFXdKPaEsBRuD9gf/rJ8mSCjTXbzRax/dM825r53yno5l3claGFY4BTTVPLtcfQpT5ihwbAIJZNGZZp60jdK9NlpIwXlW9USLDwlAJKqvAtMvJApeb1e2kfqdWk3l88p4FHfJAUD/EwjQJW/oESYVbIoPWr4p82FueprzqZnQcUO8SUovFzgjWh/2OaV4XXdzXwLFzkC7iVQLFxUpBwyC7jILDk5wHoCVuJgpAmwIawIo/BCmkcInFiem9UbpyezqhPVvf6vO1k6exG3htluiXFCO0FhmU+LuSjlR0ajX0Esp91YB4uZMpAR0JBA+aEcICkQNFKl/gveIAxBx9RbIdBRHwzwROOxn0NWr2mRxhvkcEKIoqk05ygethfLx7n5vENk6bhU2PJGsEP8EmPVV0XLuy00z58NpWN2x6XvVlUKE2sMu8jTmr3X8IOTFAgJcbWYP+JxOmXh2thhmlarFAShAiUqT1AXmKcAoHLx+Z/X+2ZQbAGbJtWhtAOWzd8oqj2QiN97M3s4I6ifC38cQ7GaJ9hG0g5Q7/Ton8Be87G+cerTNHZ5ZnYSSpVtyhcOIyCqafSf4C4pkmusNSRA9KVnkbcUeSHud/1AGAAipCMxur8FUR9JqLFdEiThlM4ZqUtecb21YAHz2v07qLzArjUisOrw1wU2mEqVwwQxaiZoQST/97jJc35qi54Vpgqfo= Server: Oracle-Application-Server-11g



SEQ 13 – Resource WebGate globex.idfocus.com sets OAMAuthnCookie

The browser gets a HTTP 302 to go back to http://globex.idfocus.com/ and when the Resource WebGate gets the encrypted token it validates that this is a valid session.  At this point an OAMAuthnCookie for globex.idfocus.com is generated and now the browser has a token set for both globex.idfocus.com and acme.melander.us.  So the browser is never challenged a second time.  Surprisingly this functionality is nothing special to do with DCC, it is a normal way that the 11g WebGates work together in a multi-domain SSO fashion.  But I wanted to point this out so that there are misconceptions that DCC is special in this regard. HTTP/1.1 302 Found Connection: Keep-Alive Content-Length: 212 Content-Type: text/html; charset=iso-8859-1 Date: Fri, 12 Sep 2014 12:04:05 GMT Keep-Alive: timeout=5, max=99 Location: / Server: Oracle-Application-Server-11g Set-Cookie: OAMRequestContext_globex.idfocus.com:80_783376=;expires=thursday, 01-jan-1970 01:00:00 gmt; httponly; path=/ Set-Cookie: OAMAuthnCookie_globex.idfocus.com:80=vh4qf6d43e5MU0UVWdzO%2BZ43786Zl1C%2F3kHaW6XM%2Bz%2BrLD%2F%2FKC4sJQdZZYLcrcM7WnYjZCQFRqM5YvGypLkxDyQMuFxdQcrltEseZC1FNErkGHaL5HDR8FJxxf%2B3KP5XPL6z882pWt2P4IaHe3V630%2BaHePEabNeL%2BtU6VD5hgFXPxJRo9tM6FZB%2BRy47QkWhBqqWlI1opTk8r71M8q5mi7tG3VeayG1eT1nj1FjGC1dRn0Py280pMQf9BR6WKKW5De%2BblW0PE3b4aa%2BWuC2Dxc1hzzjTQzIbuaxTsaGIGoY13Ri2uxwY%2BMvhTk0rMtl9u2QSmJwX4cmwKRdvM47wRCxvZ%2BaMTU8UhcdIOZWHh4S2A77jwMr2507SYdPXOwXMUwksSlF4WyjIQSkksmhr3ZbMVYMxP3QLfFwqN19Q05OT8ZM1lNtYF3L%2FPD3orcwBb9OjJ%2FiMsfhSUZsfNB9ngaFBrNbR49FI2HkLgVPW9g%3D; httponly; path=/



Let’s exit this party with multi-domain Logout

The reason I dragged you through sequence 13 where we got to http://globex.idfocus.com/ via the SSO session is so I can get into the multi-domain logout.  A lot of focus seems to always be on the login, but I feel the logout is often forgotten because frankly ---- it’s not as sexy.  I aim to change that.  Logout can also be a bit tricky and especially multi-domain logout.  In this section I want to continue with the same sequence diagram to close this article and give some important bits on this type of logout, but again in Part 2 I will get into more detail with the configuration needed to accomplish it.

SEQ 15 – Request the logout.pl page to logout!

This sequence shows the browser sitting at the globex.idfocus.com domain and then requests a logout.  Logout is configured in the WebGate profile, which is fairly normal.  However with DCC the logout is a bit different and it requires some configuration on both the Resource WebGate and DCC WebGate profiles.   In addition the logout.pl has to be on the DCC WebGate and does some tricks of its own, more on that in sequence 17.   So in this HTTP trace you can see that the logout request is for the relative URL /sso/logout; this triggers the logout sequence and is the actual value found in the Logout URL parameter of the Resource WebGate.  Then the end_url is the Logout Target URL parameter that holds the landing page the browser needs to go to after it has completed destroying all the session cookies and the session in OAM. GET /sso/logout?end_url=http://sso.melander.us/sso/logout.html HTTP/1.1 Host: globex.idfocus.com Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Cookie: OAMAuthnCookie_globex.idfocus.com:80=vh4qf6d43e5MU0UVWdzO%2BZ43786Zl1C%2F3kHaW6XM%2Bz%2BrLD%2F%2FKC4sJQdZZYLcrcM7WnYjZCQFRqM5YvGypLkxDyQMuFxdQcrltEseZC1FNErkGHaL5HDR8FJxxf%2B3KP5XPL6z882pWt2P4IaHe3V630%2BaHePEabNeL%2BtU6VD5hgFXPxJRo9tM6FZB%2BRy47QkWhBqqWlI1opTk8r71M8q5mi7tG3VeayG1eT1nj1FjGC1dRn0Py280pMQf9BR6WKKW5De%2BblW0PE3b4aa%2BWuC2Dxc1hzzjTQzIbuaxTsaGIGoY13Ri2uxwY%2BMvhTk0rMtl9u2QSmJwX4cmwKRdvM47wRCxvZ%2BaMTU8UhcdIOZWHh4S2A77jwMr2507SYdPXOwXMUwksSlF4WyjIQSkksmhr3ZbMVYMxP3QLfFwqN19Q05OT8ZM1lNtYF3L%2FPD3orcwBb9OjJ%2FiMsfhSUZsfNB9ngaFBrNbR49FI2HkLgVPW9g%3D; OAMAuthnHintCookie=1; oam_cn=Anne-Louise Barnes; oam_email=abarnes@acme.com; oam_userid=abarnes Referer: http://globex.identityfocus.com/



SEQ 16 – Process logout.pl to logout

This sequence shows the browser getting the HTTP 302 to redirect to the logout.pl page along with the URL encoded value for the end_url.  Notice the Expires -1, this is basically the Resource WebGate on globex.idfocus.com killing the session cookie for the OAMAuthnCookie_globex.idfocus.com.  However we are not over yet because we need to destroy the sessions for all the other domains, in this case acme.melander.us and globex.idfocus.com. HTTP/1.1 302 Found Cache-Control: no-cache, no-store Connection: Keep-Alive Content-Length: 311 Content-Type: text/html; charset=iso-8859-1 Date: Fri, 12 Sep 2014 12:04:08 GMT Expires: -1 Keep-Alive: timeout=5, max=96 Location: http://sso.melander.us/oamsso-bin/logout.pl?end_url=http%3A%2F%2Fsso.melander.us%2Fsso%2Flogout.html Pragma: no-cache Server: Oracle-Application-Server-11g Set-Cookie: OAMAuthnCookie_globex.idfocus.com:80=;expires=thursday, 01-jan-1970 01:00:00 gmt; httponly; path=/ Set-Cookie: OAMAuthnHintCookie=;expires=thursday, 01-jan-1970 01:00:00 gmt; httponly; path=/; domain=.identityfocus.com



SEQ 17 – Kill those OAM Login Sessions now!

This is in my opinion one of the most interesting sequences of them all.  That is the sequence that makes a call to /oam_logout_success.  This URI is triggered because of the Logout Callback URL configuration in the WebGate profile.  It is responsible for killing all the remaining OAM SSO sessions.  In fact to verify all one does is logout and make sure the oam_logout_success is called as I explained, and then go into the OAM Console and go into the Session Management tab to search for the Username.   Before logout you would see the account session and then after the logout it should disappear.   In Part 2 I will get into more detail on logout configuration and how to customize the logout. HTTP/1.1 200 OK Date: Fri, 12 Sep 2014 12:04:08 GMT Server: Oracle-Application-Server-11g Pragma: no-cache, no-cache Expires: -1, 0 Cache-Control: no-cache, no-store, no-cache, no-store Generated-By: login.pl Set-Cookie: OAMAuthnHintCookie=;expires=thursday, 01-jan-1970 01:00:00 gmt; httponly; path=/; domain=.melander.us Set-Cookie: OAMAuthnCookie_sso.melander.us:80=;expires=thursday, 01-jan-1970 01:00:00 gmt; httponly; path=/ Keep-Alive: timeout=5, max=96 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 Content-Language: en ---------------------------------------------------------- http://acme.melander.us/oam_logout_success



SEQ 18 & 19 – Redirect to the logout landing page.

If you remember from sequence 15, there was an end_url, which basically was the parameter that held the value for where the browser will end up after the logout process is complete.  This value could be anything you want and in my case I decided to have it land at /sso/logout.html on the sso.melander.us DCC WebGate; just make sure this URL is unprotected or excluded in the policy.  So this ends the logout. HTTP/1.1 200 OK Cache-Control: no-cache, no-store, no-cache, no-store Connection: Keep-Alive Content-Language: en Content-Type: text/html; charset=UTF-8 Date: Fri, 12 Sep 2014 12:03:28 GMT Expires: -1, 0 Generated-By: login.pl Keep-Alive: timeout=5, max=96 Pragma: no-cache, no-cache Server: Oracle-Application-Server-11g Set-Cookie: OAMAuthnCookie_sso.melander.us:80=;expires=thursday, 01-jan-1970 01:00:00 gmt; httponly; path=/ Set-Cookie: OAMAuthnHintCookie=;expires=thursday, 01-jan-1970 01:00:00 gmt; httponly; path=/; domain=.melander.us Transfer-Encoding: chunked GET /sso/logout.html? HTTP/1.1 Host: sso.melander.us Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Referer: http://sso.melander.us/oamsso-bin/logout.pl?end_url=http%3A%2F%2Fsso.melander.us%2Fsso%2Flogout.html



What have we learned?

So what we have learned from the HTTP Traces is that both ECC and DCC submit credentials to the URI /oam/server/auth_cred_submit, but DCC submits those credentials directly to the DCC WebGate host.   The DCC WebGate creates its own unique DCCCtxCookie and all other Resource WebGates still create OAMAuthnCookie SSO tokens whether they are used for DCC or ECC scenarios.  At the end of the day the biggest difference we can gather is that DCC makes it easier to secure the OAM Server, as I mentioned earlier, because there is no point where requests from the browser are sent to the OAM Server and therefore mitigates any risk of exposing the Mid Tier in regard to OAM.   However logout is a bit different in regards that it has to run from the DCC WebGate and if you have a multi-domain SSO configuration like I had oam_logout_success is required to be configured and called by the logout.pl or possibly another way using a custom logout.  Until Part 2, I hope you have a little deeper understanding of what is going on under the covers of DCC.