Support for NTLM - ORDS, SODA & JSON in the Database

Does the Apex Listener support Windows NTLM authentication? We currently use Apache/OHS mod_ntlm for this purpose. If the Apex listener doesn't support NTLM we wouldn't be able to use it.
Thanks 

I'm looking into exactly the same right now. My setup is 11gR2 using APEX 4 running in the APEX Listener on Weblogic.
Using the Oracle White Paper at Technet, I've set up my authentication scheme. The only trouble I'm having, is that I have no idea how to set the CGI environment variable in the APEX Listener or in Weblogic. Or if this is even necessary.
When I run my application using this setup, I get a popup asking for username/password, but anything I fill in will log the user in. And instead of <domain>/<username> the application shows <weblogic_server_name>/username. 

Not sure if you guys saw this but Jason has a write up on it. The listener has nothing special for NTLM and the pl/sql method used before should still work.
http://jastraub.blogspot.com/2008/03/ntlm-http-authentication-and.html
-kris 

Yes, I am aware of Jason's blog entry but from the long string of updates, it doesn't appear to be a very stable solution especially since a Microsoft hotfix/patch can break it without warning.
Update 08/14/2009: I also want to point out some text from the whitepaper based on this article to make it clear what this function does (decodes an NTLM token) and does not do (negotiate anything with any domain controller)."This paper presents a pure PL/SQL code solution for decoding an NTLM token and using that decoded value as the authenticated user in APEX applications. The function will set the username to "nobody" if it detects that the browser prompted the user for their credentials instead of just silently negotiating them. You can then write authorization schemes that deny access to the "nobody" user. Note that unlike the mod_ntlm Apache module, this solution does not pass along credentials to a domain controller for authentication. This solution requests that the browser present an NTLM authentication token and decodes the username and domain from that token."More importantly, as per the last update (quoted above), it doesn't actually verify credentials with a domain controller like Apache mod_ntlm does. Assuming that the new Apex listener is the recommended "web server to proxy requests between the browser and the Apex engine", IMHO there should be a more robust NTLM authentication method that actually verifies credentials with the domain controller instead of a (very clever) hack. 

"More importantly, as per the last update (quoted above), it doesn't actually verify credentials with a domain controller like Apache mod_ntlm does. Assuming that the new Apex listener is the recommended "web server to proxy requests between the browser and the Apex engine", IMHO there should be a more robust NTLM authentication method that actually verifies credentials with the domain controller instead of a (very clever) hack."
The lack of a robust 'Single Sign On' method with the apex listener is a virtual deal breaker for me and at least one other environment I'm aware of. Apex is a superb solution for many typical Forms/Reports applications running on corporate/large/normal intranets. These environements are going to be using Active Directory and the applications will be competing against Sharepoint and .NET applications that will probably be running with native windows authentication. It is a real bugbear to me when I'm forced to login to a Windows app and prompted for a password when I know it could have been configured to not to. When I'm on a Windows database I make extensive use of native (NTS) authentication as it is trivial to configure and then gives the massive security and convenience benefit of allowing passwordless database accounts. You immediately get all the built in auditing of knowing people aren't sharing accounts among other benefits.
I assumed that getting some kind of ntlm authentication would be easy to get running on Tomcat but I'm struggling to find something so currently I'm sticking to proxying via Apache using mod_auth_sspi (unfortunately needing a Windows host) or mod_ntlm (which is a bit unsupported currently, but does work.)
It would be a massive boost to the Apex project to have a working native Windows authentication method as that is the environment where most Apex applications are going to be running. 

I have been looking into this a lot lately, and I have been able to only find one Java provider with NTLMv2 support: http://www.ioplex.com/jespa.html
I have been looking at doing basically a CAS service, call on a page sentry, which will forward out to the j2ee authentication portal app, which, if the NTLM is set and proper, which configure a proper CAS session and forward them back into APEX with the proper credentials. Just like normal CAS only it will pickup for NTLM.

Related

Oracle Apex Listener and User Authentication via OID and Active Directory

Hi
My architect is proposing that the apex database for a new application can use the Apex Listener to Authenticate via OID or AD instead of setting up the authentication via apex itself. Could you confirm that it is possible to do the authentication in this way via Apex Listener on one server and therefore there would be no requirement for the database sever where Apex is installed to know the host and port details of the OID or AD server. - there would just be a sqlnet connection between the server where the Apex listener is installed and the server where apex will be installed.
Thanks
Vickie 
The Apex Listener only authenticates for the Manager, and Admin roles used to configure and manage the listener. To do this, it can use the authentication services provided by your application server. But the servlet that actually provides the bulk of the listener's functionality is usually unauthenticated. I suppose that you COULD change web.xml to force authentication of this servlet, but I wouldn't.
It is designed to use the authentication services that are built into Apex itself, in that it will initially connect to the database as the low-privileged user, APEX_PUBLIC_USER, then present a login screen for the user to identify and authenticate him/herself. For most people, this is fine - Apex's built-in authentication capabilities can use OID, AD, and several other authentication methods. And you can build your own in PL/SQL. If you need some more help with how to use the built-in authentication in Apex, I suggest that you ask in the Apex forum - it will be the same whether you use the Apex Listener, or mod_plsql, or DBMS_EPS.
Of course, if you aren't using Apex, and are using the Apex Listener as a front-end to other PL/SQL Web Toolkit applications, you will have to build your own authentication method. I've done this with DBMS_LDAP, and I can provide some sample code. 
Thanks - this is what I thought and setting up the authentication Apex for OID or AD looks quite stright forward, yes it is for an Apex application 
I can say this much about APEX Listener. It is nothing but a front end interface, just like mod-plsql is with OHS. All of your application authentication actually happens within the APEX processes on your database server. OID SSO is controled and triggered at the database server and handled there as well. I know for a fact that OID, LDAP, and Internal Authentication of APEX works fine through the listener. 
Hi David,
I currently have APEX (4.0.2) running through the APEX Listener (1.1.2). I'm trying to use APEX LDAP authentication, but am not able to through the listener. I get a 'failed to authenticate' error. If I access apex through Oracle's HTTP Server, I have no problems with authenticating with LDAP (with the same exact LDAP configs). I was wondering if you had to make any Listener configurations changes in order to get LDAP working via APEX Listener?
Thanks!
Julie 
I am looking for an answer for a similar question. I think follow link about the authentication and authorization using OID and OOS with APEX may give some hints for this question:
http://www.patrickhaston.co.uk/plsql/oid_authorisation.html
Edited by: user9516763 on 30-Sep-2011 10:27 AM 
Our APEX Listener worked out of the box. I would think that from what your describing here you may have a configuration problem at your Database. You can test this by writing a PL/SQL procedure that will go out and authenticate with your LDAP. If that works, then APEX should work. We have 2 main authentication servers here (OID and LDAP). The only modifications we had to make to the listener were due to an Oracle "Unpleasant Feature" where they defaulted your configuration to only be located within your /tmp folder so it was constantly being erased. I still edit the new versions of the listener because I do not store my config file in the default location. As far as SSO working, that worked out of the box, you just may need to reinstall it because when we upgraded our APEX it got nerfed by the upgrade. We use only the default built in LDAP Authenticator functions though so if your doing anything custom that would be where to start looking. Variable handling changed somewhat in the APEX Listener when it comes to your session so if you use envrioment variables, you may need to dig alittle and make sure you are getting what you need. Some of those have to be pulled a different way on the APEX Listener and then put where APEX thinks they should be. We never had any issues there but be aware we are still in APEX 3.x.x so you might have something specific to 4.x.x.

How to enable HTTP Basic Authentication

Hi,    is it possible to enable HTTP Basic Authentication when creating RESTful services in ORDS or APEX 5.0 ?Thanks in advance for your feedback
I'm also curious about this. Here's some more details. Let's say we have a bunch of applications that were built using the OWA toolkit and accessed through a bunch of DADs configured with mod_plsql running on Oracle Application Server. Some of those DADs offer up unauthenticated applications and the username/passwords are stored in the DAD. Some of the DADs offer up secured applications where each user uses a database username and password through basic auth to connect to the application. Oracle Application Server and mod_plsql have been replaced with Oracle WebLogic and ORDS. We've configured an ORDS "database" that can serve up the public applications, but since the username/password combination is stored in the ORDS configuration we have yet to see how to configure ORDS so that it prompts for the database username and password the way a DAD/mod_plsql combination did in the past. Potentially an APEX application that used Database Authentication could be used to protect the OWA toolkit based applications, but before we go down that path we'd like to understand if we are missing something simple that we could do with ORDS to give us the same behavior we had with mod_plsql. Thanks, Rich
For REST calls, it's just automatically there.  If you set a REST call to secure, and have users configured in the webserver you can use that. >>   is it possible to enable HTTP Basic Authentication when creating RESTful services in ORDS or APEX 5.0 ? For mod_plsql style DB Auth , it's on our list but not there yet.>>DADs
Hi, my initial question was about RESTful Services created in APEX 5.0, is there a way they can be protected through BASIC Authentication ? thanks
I just tested it to be sure and and REST calls built/defined in the APEX side can not be secured with Basic.  The ORDS plsql calls are pretty easy to use just look at the ORDS package or use SQL Developer for a GUI for defining the REST. -kris
As for mod_plsql style DB Auth, I'm glad to hear it is on your list, Kris.  I hope it gets there soon, because mod_plsql itself has been deprecated.  I still have applications that rely on this. As for the original question:What if you edit the web.xml in ords.war (or whatever you named your ords deployment) to configure BASIC authentication there - created roles and security constraints?  Of course, you'd need to do some application server configuration too to set up a security provider. If I try this myself, I'll let you all know if it works.

How to use different (not local) user for NTLM auth in Authenticator?

Hi All,
I use custom authenticator to provide user / passwords to connect to .NET Web Services. I overloaded function getPasswordAuthentication() that returns right user / password combination for the requested URL. It all works perfectly for many kinds of HTTP connections: basic, ntlm, ntlm-v2, through proxy, ssl, etc.
My problem is that during NTLM authentication from Windows computers JVM uses credentials of the currently logged in domain user instead of calling Authenticator to get other user / password provided by the user. In case when local user credentials fail to authenticate, JVM calls my Authenticator but in case authentication is successful it does uses local domain user and never calls my Authenticator. The issue is when this local domain user does not have enough permissions but authenticated correctly there is no way to supply JVM with another user to begin with.
What can I do to force JVM to ignore local domain user and to use Authenticator to collect credentials during NTLM authentication requested by the server in case the software runs on a Windows box with currently logged in domain user?
I am looking for the answer for a long time already but found only questions and suggestions to switch server from NTLM authentication which is not an option for me. From the developer's view it has to be pretty simple change for Sun to do in Java networking API. Is there any way to escalate it to Sun support? Maybe there is some property in some JRE patch level that allows to do this?
Thank you very much!
Mark 
You can certainly buy support from Sun. Whether that support would extend to having them produce a customized JRE for you I don't know, you would have to discuss that with the salesperson.
If you're thinking of filing an RFE to get that changed in a future version of the language, you could do that too, but don't hold your breath waiting for it to happen.
However... I'm not clear exactly on your setup, but if you are making an HTTP connection to something which requires NTLM authorization, you could try installing an NTLM proxy server. Then use that as your HTTP proxy. I use it for connecting from Java (from a non-Windows machine where NTLM isn't available in the JRE) through a Windows ISA server to HTTP sites on the Internet. You can get it at [http://sourceforge.net/projects/ntlmaps/] although Sourceforge appears to be down just at the moment. 
Thank you for the reply. I have kind of an opposite problem. I can perfectly connect from Linux computers to Microsoft IIS servers using NTLM or even NTLMv2 authentication. My problem is connecting from Windows client computer joined to the same domain as IIS server with the domain user logged in to this computer. In this case this user account will be used in any HTTP connections I initiate to this IIS server instead of the one that I want to supply in my custom Authenticator.
I have graphical interactive application that connects to IIS Server. When user runs it and connects to IIS server I want to prompt for the user/password regardless whether JRE may correctly authenticate using current user account credentials. The current user may not have enough permissions in IIS application so I want to use different user to login to IIS application.
Thank you anyway,
Mark

Sun Access Manager integration with SharePoint for SSO and Federation

Hi,
One of our clients has SharePoint 2003 and 2007 currently being authenticated and authorized by AD. They are looking for SSO and and are interested in providing federated access to partner users. They have Basic and Cert based authentication currently. I came across this article http://developers.sun.com/identity/reference/techart/sharepoint.html which says how to configure Policy Agent on IIS to achieve SSO. But it says this mechanism only supports basic authentication. Has anyone been able to make it work for certificate based authentication also? Also, how well does it work even for basic authentication configuration? Does it work fine for federated users?
Thanks,
Sanjay 
Current versions of AM just copy the users password they put in for auth over to IIS as they log in (so passwords must be synced between AM and AD). So it won't work for certs or federated users. Maybe next AM based off of opensso will work better as it will have WS-Federation support.
https://opensso.dev.java.net/public/use/docs/opensso/pdf/WSFedHowTo.pdf 
Thanks a lot for the information. I was wondering, if IIS is configured for anonymous access so that AM does not need to send user password for second (local) authentication with AD, would it work? AM would still need to send uid (or CN or some equivalent) so that SharePoint could do fine grain authorization. 
AM would still need to send uid (or CN or some equivalent) so that SharePoint could do fine grain authorization.I think someone would have to write a sharepoint auth plugin to make that work. As it is sharepoint gets a lot of info from the underlying Windows OS about the logged in user (relying on OS impersonation in IIS and doesn't just rely soley on REMOTE_USER). I don't know much about the latest versions of sharepoint though, so someone who knows more should comment.

ID Server and Policy Agent for AS .. is secure?

Hello there,
I have a question. Quite critical question, concerning iPlanetDirectoryPro cookie. If I've got it right, this cookie contains SSO Token. And the SSO token can be used with identity server to obtain any SSO assetion. I've experimentaly confirmed this.
Now, can anyone tell me why this cookie is sent to any host in my domain? The default after instalation is "bgs.sk". This default value enables any host in my domain to impersonate me. Well, I still can change this, but it is now good to have insecure default values anyway, is it?
Second, and more critical problem: I have Policy Agent installed on my Application Server. It looks like the agent requires access to the iPlanetDirectoryPro cookie to work correctly. But, if my application server has my SSO token, it can impersonate me anywhere. Not a good situation at all. That would mean security hole as big as hangar doors.
Are my assumptions correct? Am I overlooking something?
(All valid for ID server 6.0 and Liberty protocols)
Thanks for any help. 
Cookie is sent to IS agents inside your domain to identify and validate your session. In a normal enterprize network whole domain, e.g. bgs.sk, is owned by your company. You can limit your cookie path to a sub-domain.
Application server will not "impersonate you" by itself, unless you will configure it to do so. Imagine a scrapping portal which connects to the back-end on your behalf and represent you a consolidated information page.
Certainly Netegrity's product uses a better approach: cookie is encrypted using a dynamic secret, shared between identity server. SunONE IS sends cookie virtually in a clear text. 
But this approach completly ruins Liberty mechanisms. Try to read any literature on security protocols and try to find a Needham-Schroeder protocol story for a lesson on impersonation.
As to the trustworthiness of Application Server: AS runs many applications and not all of them are trustworthy. Any of these applications can read my ssoToken in a cookie. Any of these applications can impersonate me anywhere. Really a great weakness. 
In addition to numerous security holes in the product itself, any user can run network sniffer and capture your cookie.
What is your proposal for improvement? 
My proposal? Simple: Stick to the Liberty specification and make no short-cuts.
But I would like to hear Sun's reaction to this issue. 
This is a very good point.
I am working hard to find out if the policy agents are Liberty compliant. Form the user session lifecycle doc it doesn't look like...
http://docs.sun.com/source/817-5707/appB_sessionlifecycle.html
I couldn't figure out if there is a "mode" of the agent that is Libery compliant.
Is really hard to relate the agent to any of the Liberty standards. What is really confusing is that one of the samples inside the liberty samples folder is based on the web agents...
Does anyone know if the agents are Liberty compliant and at what level ? 
Although Sun promote Identity Server by emphasizing its Liberty/SAML feature, the product itself use a proprietary protocol for SSO and CDSSO.
As all we know, this product could be totally useless without Sun's Policy/J2EE Agent deployed. But ironically these agents communicate with Identity Server in its own way, nothing to do with SAML, XACML, or even SOAP.
The agent approach is usually not a good idea. We saw more and more problem raised from fields related to agent stability and scalability. We never see any performance benchmark data from Sun. Since the communication between agt and Identity Server are proprietary, no ISV can make agent for this product. You have to wait for Sun for agent support if you have new system not on the support matrix.
In addition to agent, another big issue of Identity Server is its complex DIT structure. In fact, we prefer to have RDBMS as Identity Server's repository. Sun abuse ldap just because this company doesn't have any database product but still want to provide a pure Sun platform (JES) to customer. So they compromise the architecture for business reason, I'd like to tell you, I don't like the way Identity Server store data in DIT, I don't like the console UI (its for technical geek), and on one in our company dare to do any configuration change.
Now Sun put Identity Server as the core of its JES product stack. If you have time to take a look at how the SJS Portal use Identity Server and how SSO between Portal channel and Email/Calendar Server are achieved, you'll find that you just buy a "framework" (I mean Identity server), not a product, because you have to do every integration work by intensively coding.
I predict that Identity Server will be significantly rearchitctured in the near future, otherwise we don't see any benefit this product can bring to me. It is a headache for deployment as well as maintenance. If you just need Single Sign-On, there are lots alternative to achieve, Sun's Identity Server is really overkill. It's authentication feature is ok, but authorization feature (policy, role) is very limited. If you have lots of Windows/IIS web app need to do SSO with Identity Server, god bless you... you better have a sharp programmer to wrap up the C API so as your ASP programmer can leverage Identity Server SDK, and you got to pray for IIS agent behave well. In addition, don't forget to learn more about JATO if you want to do some fancy customization on the default login page.

Categories

Resources