Re: Apex, ORDS3, Tomcat7, Windows Server, SAML 2.0, and Amazon

Hi Bill

I have done authentication using federation protocols (SAML and OIDC) in the past using many different ways. However, let me start by saying that later versions of APEX now also support OIDC out of the box. So you might want to go that route.
If your IDP supports SAML 2.0, it might also support OIDC. Someone will probably chime in and tell us what versions of APEX support OIDC. Anyway - SAML is a bit more daunting to configure because of metadata exchange and the heavy use of XML signing and encryption methods for the SAML assertions. Here are some of the ways I have done SAML and/or OIDC on 'older' versions of APEX.

1. SAML using a SUN/ORACLE/FORGEROCK J2EE FEDLET. The fedlet is a piece software you can deploy in tomcat next to ORDS - it acts as SAML SP. So you configure the SP and exchange SAML metadata with the IDP. It comes with some JSPs - so I rewrote them to : - save the SAML assertions of the SAML response to a db table - generate a unique key for the SAML response - return the unique key via a 302 redirect to APEX - wrote a custom auth in APEX to
   -->get the unique key
   -->lookup the assertions based on the key
   -->authenticate within APEX using the assertions (JIT identity provision is possible here if needed)
   -->delete the assertions to avoid replay
   
2. OIDC using a reverse proxy in front of APEX I used ForgeRock Open Identity Gateway (OpenIG) for this. This *used to be* open source - someone however has forked it here : http://www.openidentityplatform.org/

However, you could just as well use Apache HTTPD using mod_auth_oidc which does basicaly the same - act as OIDC relying party for an OIDC authorization server. Getting a OIDC RP to work with a OIDC AS is much easier than SAML. You basically need a client_id and client_secret like with OAuth2. There are different flows possible but in the end the RP should receive a JWT(S) token which is the OIDC equivalent of SAML response. It contains 'claims' and as such has the usercontext.
OpenIG or mod_auth_oidc can then generate http request header from your claims and proxy them to APEX. You could use the APEX authenticator based on http headers to authenticate your session.

Your question regarding putting Apache HTTPd in front of Apex - we do this all the time. Apache acts as reverse proxy - we also use mod_security with the OWASP core rule set. If your APEX app will be publicly available, this is highly recommended. So your option to use apache with mod_auth_mellon seems also a good choice - easier I think than using a FEDLET as you could probably propagate user context through http request headers, and then again could use default http header authenticator in APEX.

If you find the learning curve for federation protocols too steep - i would recommend using the OIDC authenticator in the more recent APEX verions.

kind regards
Kurt

Van: "Bill Ferguson" <wbfergus_at_gmail.com> Aan: "oracle-l" <oracle-l_at_freelists.org> Verzonden: Woensdag 30 januari 2019 15:14:04 Onderwerp: Apex, ORDS3, Tomcat7, Windows Server, SAML 2.0, and Amazon

Hi all,

I currently have an environment of Windows Server 2012 R2, Oracle 12.1, Apex 5, and Tomcat7 (with organizational wildcard certificate). I am also only using LAP authentication, as I have never in around 15 years been able to get the LDAPS authentication to work, and our LDAP administrators seem to be even more lost than I am. Also, later this year I am tasked with migrating my two systems to the Amazon cloud.

So with that basic info out of the way, the IT network security Nazi's finally noticed that I am doing cleartext password authentication, and told me to convert to LDAPS. They don't care that the LDAP admins are clueless as to why I have always been unable to get Apex to authenticate, they just demand it get done.

Since I am also tasked with migrating everything to the Amazon cloud, my agency also has the mandatory requirement that all authentication in the cloud has to be done with SAML 2.0. So rather than waste my time with LDAPS, just to switch in a couple months to SAML, I'd rather spend my time productively with SAML.

And this is where I have a bunch of questions. Some may be easy, or even apparent, but I've been trying to wrap my head around how it will al work in the Amazon cloud and been completely befuddled.

First off, I haven't found anything on the web about SAML in the Windows environment with Tomcat. The best resource I found is witha Linux environment, but along with the Tomcat webserver, he also is using the Apache HTTP server. This appears to me as he is using two web servers? This seems so confusing and unnecessary, but I'm probably missing something. Could it be bacause of the requirement to use the 'mellon' packages (and something else, I forget which one), the only way to get them integrated into the environment is with the Apache HTTP server, and then Tomcat itself is then needed to complete the communication to Apex?

Next question would be if anybody has any experience with all of this as it pertains to a cloud environment, preferably the Amazon cloud. In this regard I am confused about how the parts work together. The Oracle database part residing in the cloud I understand, I'm having problems figuring out how the Tomcat webserver, URL addressing and authentication would work.

Will I keep a machine running locally with the Tomcat web server, which will communicate to the Amazon cloud, determine it is a new connection for the day, then relay the authentication request back to Tomcat to then contact the 'identity provider' (is that an Active Directory server or a LDAP server?), get a token, then attach that token to all communication back and forth to the database? Or does the Tomcat installation reside in the cloud as well (requiring a different Amazon configuration, CHS vs AWS)?

Am I making any sense of this, or am I simply more lost than I know I already am? Thanks for any and all constructive assistance or suggestions.

--

• Bill Ferguson

--

http://www.freelists.org/webpage/oracle-l Received on Wed Jan 30 2019 - 15:58:30 CET