I'm trying to setup “Certificate-Based Mutual Authentication” in my Java EE application. My requirement outline as follows,
Deploying a web application (Java EE on IBM Webshpere) which is pulicly available in www, but access privileges were given only for authenticated clients via certificates.
Can someone provide me a sample code & setps that I have to follow to achieve my requirement.
As Stas mentioned you haven't stated anything about your application (what is the app server etc).
If your set up is WebSphere and you want to set up SSL mutual authentication, then this paper should give you a good idea:
http://www.ibm.com/developerworks/websphere/techjournal/0612_birk/0612_birk.html#sec1
The references in this article also contain good information and they should help you out.
Regarding Web Server, SSL hops would be between your App Server and the web server on the other end (and not to the WAS Server running). This does not change any configuration or the set up but you should be aware that your SSL communication would be till the web server and the web server might talk SSL to the back end application server and this depends on how it is set up.
If you provide additional information then folks here would be able to help.
HTH
Manglu
Related
I am hoping someone can help me out with a frustrating configuration problem I'm having with IBM FileNet Content Manager 5.2.1 (aka P8 5.2.1).
We have an existing system setup that uses Microsoft Active Directory as our LDAP directory service for P8 and that has worked fine to date. That said, we are now wanting our .NET apps to talk to P8 (via the Content Platform Engine .NET API) using WCF instead of legacy (and now deprecated) WSE but we have run into a problem. WCF requires that all communication occur over SSL - on the surface, not a problem. If you want to talk to the IBM Content Platform Engine (CPE) over SSL however, according to IBM's documentation, you must also change the underlying default LDAP connection from unsecured to SSL as well (in the process, changing LDAP to use port 636 instead of 389).
Following both Microsoft's and IBM's docs, I first enabled LDAP over SSL on Active Directory and tested accordingly. Using Microsoft's LDAP utility, ldp.exe, I can successfully connect and bind to Active Directory on port 636 over SSL.
The next step however is where I hit a wall - Enabling SSL for Content Platform Engine. I followed all the steps involving adding the Active Directory Server's CA certificate to the CPE's application server keystore - no problem. The next step in the configuration instructions however asks you to start the Administration Console for CPE (ACCE) and reconfigure the directory configuration properties - telling it to use SSL on port 636 and... KABOOM! When I attempt to save the configuration, the save fails, stating
An unexpected exception occurred. Message was: Failed connecting to ldap://ad1.domain.com:636
Unfortunately, I can't find any additional info as to why it failed to connect - I assumed it was due to something minor, such as a port conflict. To test that theory, I installed Microsoft's LDAP test utility on the CPE server and attempted to connect to the Active Directory Server over SSL on port 636. Much to my surprise, that worked just fine - grrrr...
I am now at something of a loss as to what to look at next. Anybody out there with experience configuring CPE to use SSL in an Active Directory environment?
Thanks in advance for any-and-all assistance.
WCF requires that all communication occur over SSL - on the surface, not a problem. If you want to talk to the IBM Content Platform Engine (CPE) over SSL however, according to IBM's documentation, you must also change the underlying default LDAP connection from unsecured to SSL as well
This is not true. FileNet can work with non-secure LDAP, while at the same time working with WCF.
Now, if you would like to solve why FileNet will not connect to a secure LDAP, then you should start with your WebSphere
Check WebSphere's Keystores to ensure that the AD's key is contained. Follow #M.Tamboli's advice and restart WebSphere.
Also make sure that you check WebSphere's SystemOut.log logs, as you may find more info in there.
I'm not sure if it is necessary, but you may also want to add/change the LDAP config that is setup within WebSphere itself.
I have the following implementation in testing environment,
Front-end Server [IBM HTTP Server + IBM Websphere plugin],
WLServer1 [IBM Worklight 6.2 + IBM DB2 10.1+ Liberty Farm 8.5.5.1] and
WLServer2 [IBM Worklight 6.2 + IBM DB2 10.1+ Liberty Farm 8.5.5.1].
plugin-cfg.xml has been generated from each Worklight server and merged.
The request[http] from multiple devices has been directed to worklight server's alternatively, once the merged plugin-cfg.xml has been deployed in Front-end server's IBM Websphere plugin.
How I can implement the same to serve HTTPS request.
And also I have implemented the "UserCertificateAuthenticationProject" from the Worklight modules which connects the device[HTTPS] to Worklight server directly.
Note Tested it on Android only.
Help me to understand, How I can achieve HTTPS in Test environment via IHS.
What should be the procedure in Production environment?
Note IBM Worklight 6.2 supports Android, IOS, Blackberry & Windows, so I have to implement in all platforms.
It sounds like the problem you are having is similar to this one: https://stackoverflow.com/a/21914147/2245921 The Unresponsive Host error occurs for one of two reasons:
Your device cannot reach your server (they are not in the same network)
The device does not trust the server's certificate
Since you can connect to your HTTP connection, it is not #1, so it should be #2. The answer to the other question I pointed to above should fix your problem. Make sure to turn on trace-level logs in the WL Logger so that you can see the exceptions regarding untrusted certificates.
Edit: To expand on this answer; to use HTTPS, your server needs an SSL certificate to identify itself, otherwise the device has no proof that it is connecting to the right server and not to some random server that could be malicious. You should already have a certificate that you are using in your server; if you don't, then read on.
You usually get an SSL certificate from one of two places: you either use a certificate issued to you by a trusted Certificate Authority (e.g., Verisign), or you create one for internal testing purposes. In your case, you probably want to create your own, so you should follow the "Client X.509 Certificate Authentication and User Enrollment" getting started here, specifically the parts that talk about generating the server certificate.
Once you have that certificate set up, you should configure your server to use it; for that, follow the instructions here. After doing this, the last step is to have your device trust your server's certificate. For this, follow the last part in the getting started above, which shows you how to make your iOS/Android device trust the server. You would have to look up how to do this on Windows and Blackberry, too.
After this, you should now be able to connect successfully via HTTPS. (Always make sure that when you get an "Unresponsive host" error, that you can still connect to the HTTP console via the browser, to make sure that you are connected to the same network as your server. I know you already did this as you specified in your question, I'm just mentioning it as a reminder since it is easy to forget this.)
We are setting up replication between RavenDB instances running in server mode. The instances are in different availability zones so we need a secure connection between the servers. According this this post SSL is not supported in server mode but
should be easy to add
Is there an extensibility point in the API where SSL support can be plugged in?
The API doesn't have any place for this currently, but I'm sure it would be a welcome contribution if you were so inclined to write this and submit a pull request. The underlying server is just a System.Net.HttpListener, which can be wired for ssl.
Your entry point would be at Raven.Database.Server.HttpServer.StartListening()
You would want the SSL certificate to be as easy to configure as the hostname or port. The cert itself should probably be pulled in from the Windows certificate store.
Context
I developed an application deployed in a Glassfish 3.1. This application is accessed only by https and sometimes it must connect to third-party webservices located out the customers networks. The customer have other applications inside his network; mine is only a new one "service".
Topology approximation
Big-ip F5 is the ssl end point. The customer have in this device the valid certificate
IIS redirects by domain to the respective service
glassfish is the machine with the application (over, of course, a glassfish 3.1)
How it works
When a user try to connect to _https://somedomain the request arrives to the F5 where the SSL encryption ends; now we have a request to _http://somedomain. In the next step F5 redirects this request to the IIS and this, finally, redirects to glassfish. This petitions are successfully processed.
Points of interest
I've full control over glassfish server and S.O. of the vm where it is located. Not other applications are or will be deployed on this server; it's a dedicated server for the app and some services it needs. The Glassfish runs on a VM with a Debian distribution as S.O. This VM is provided by a VM Server but I don't know the brand, model, etc. The glassfish have the default http listeners configuration.
I don't have any more information about network and other devices and i can't access to
any configuration file of any other device. I can't modify any part of the network for my own but maybe ask, suggest or advice for a change. Network's behavior should not change.
Actually users reach the application without problem.
The used certificate is a simple domain certificate trusted by Verysign
The customer have no idea of how to solve this.
The problem
All the third party WS the application must access have an unique https access and, in some cases, the authentication required is mutual (two-way) and here we find the problem. When the application wants to connect to WS with mutual ssl authentication it sends the glassfish local keystore configuration targeted certificate. Customer wants, if possible, use the same cert for incoming and outcoming secure connections. This cert is in the F5 and i can't add to the glassfish keystore because if I do this I would be breaking Verysign contract requirements. I've been looking for a solution at google, here(stackoverflow), jita,... but only incoming traffic solutions I've found. I understand that maybe a SSL proxy is required but I haven't found any example or alternative solution for the outcoming ssl connections.
What I'm asking for
I'm not english speaker (isn't obvious?) and maybe i doesn't use the correct terms in my search terms. I can understand that this context can be a nightmare and hard to solve but I will stand... The first think I need is to know if exists a solution (or solutions) for this problem and if it (or they!) exist where or how can I find it/them. I've prepared different alternatives to negotiate with the customer but I need to known the true. I've spent tones of hours on this.
There are a couple of solutions.
1)pay verisign more money for a second "license/cert". They will be happy to take your money for the "privilege". :)
2)Create a different virtual server listening on 443 which points to a pool that has your client's server address as the pool member. Then on the virtual server, attach a serverssl profile that is configured to use the same cert you are using for the incoming connections. Then the F5 would authenticate with the same cert along with your app server would not need a client cert installed. Also, if they need to initiate a session to you, you would have to setup a virtual server with a clientssl profile that uses the same cert and requires a client cert to connect.
If your destinations may not be static addresses, then an irule(s) would have to be created to deal with that. Can be handled in 10 or later code with a DNS call in the irule and setting a node for the session to go.
If you turn on encryption in SAP between the client and the server using the Secure Network Connection, then is there a load placed on the server to do all the encryption work? How big a load? Is it equivalent to the difference between HTTP and HTTPS on a web server?
Please clarify what you want to do.
Do you just want to create secure RFC connections from the SAP GUI to the SAP system? Which 3rd party security product will you be using (e.g. Kerberos).
Will you be using Single Sign On? i.e. via an AD server. If so, where will the secure connection be - full end to end?
With encryption, the main load is during the initial handshaking between the client and the server. During this process, keys are calculated and exchanged.
See the SNC User's Guide for information.
I have not seen any references to the load on the system. I did ask SAP OSS years ago but did not get a satisfactory reply.
You cannot compare the load of SNC (using DIAG) to HTTPS because the protocols are very different - DIAG is a lot leaner.
I have investigated the use of F5 servers. They can be used for software and hardware accelleration of HTTPS, but not for the DIAG protocol.