2 Replies Latest reply on Oct 4, 2011 9:19 AM by 862536

    Separate authentication for External and Internal users?

    862536
      Hi,

      I have been asked to come up with a POC for a client who wants a new APEX system to be accessible to both internal and external users. The client’s security team want to have two separate copies of the APEX application, and two copies of the APEX listener on separate databases in two separate Weblogic servers, to support the different security requirements for internal and external users. I don’t think this is necessary as APEX should be able to enforce conditions depending on what type of user is connected, by interrogating the cookie passed in which could contain a flag to say whether the user is internal and external. In addition, VPD can be used to further restrict external access.

      The middleware solution for the client is being handled by a third party vendor, who have made the following recommendations:

      The internal route requires SSO to be configured on WebLogic where as the external route doesn’t. Internal users are to be validated against Active Directory, with RSA Authentication Manager used for external users. We can't configure an instance of APEX listener to use and not to use SSO at the same time. Hence two applications are required.

      Now, from my limited understanding of the APEX Listener, I understand it is possible to set up different rules depending on the type of user accessing it. However, could this not all equally well be handled from within the APEX application? We could write a custom authentication procedure which again would check the user’s cookie and route authentication to SSO or otherwise, as required.

      So my question is this: can it really be necessary to implement two versions of an APEX application, with two separate APEX listeners on different servers, to meet the separate security requirements here? Ultimately at the end of the day if that’s what the customer wants, we will have to build it, but I’m looking to reassure them via a POC that this will not be necessary. I think the hardware/middleware vendor are recommending this to the customer just because they are not aware of the custom authentication options available from within APEX itself.

      Please forgive any oversimplifications or lack of detail in the above – I’m more of an APEX developer than an infrastructure person, and a bit of a "newbie" where APEX Listener is concerned. Any advice gratefully appreciated!

      Graham.
        • 1. Re: Separate authentication for External and Internal users?
          Udo
          Hi Graham,

          it is a question of how paranoid people are and how far they trust their own infrastructure. Things could be easier than splitting up environments, but I'm not sure if I would just depend on the cookie, because cookie can be faked easily. But I'd think the following architecture would be safe:
          1. Internal users connect APEX Listener whatever way the security team requires, come to APEX, and may be identified using the internal IP adress (range). To fake the IP should be difficult for external users.
          2. External users connect APEX Listener through a defined gateway, preferably a proxy. All requests coming through that gateway would be treated as external users.
          You may add additional logic to that proxy, e.g. use something like "mod_headers" in Apache HTTPD to add an additional header for requests, so you could identify them as external users.
          You could, of course, also put it the other way round and let internal users use a certain proxy to put enforce some IP adress based rules, or perhaps some additional credentials like authentication for proxy access (which again could be user-transparent in AD-configuration, at least if you stick with IE).

          You can implement the separation in your custom auth process easily. But this architecture also allows for some other compromises: Even if somebody doesn't trust your application logic to handle both request types successfully, you may also use the proxy to enforce the call of a certain application id. You definetly don't need to duplicate the infrastructure...
          Most companies already have a proxy for external users, e.g. to enable SSL and for hiding other internal resources, for having load balancing, ... so I'd expect you will just have to put some configuration on the existing infrastructure and end up in needing no additional components. Even if there is no proxy yet, it would be a very light weight component, easy to handle.

          This all has, so far, nothing to do with APEX Listener. It's "just" a web front end for the APEX instance in the database. I would not put any network safety logic into that service, but split things up before. The APEX Listener might be patched to add some logic, but that's unsupported.

          I think this would work and should be sufficient for most security requirements.
          If my picture wasn't painted understandable, please let me know.

          -Udo
          • 2. Re: Separate authentication for External and Internal users?
            862536
            Thanks again Udo. The middleware team are happy to consider a single server solution now, and I'm sure your input will help us along that road.