I am trying to establish a connection to a ldap in gwt. Thanks to a former post
( GWT JDBC LDAP connection fails ) I was able to at least contact that server. However, even though I put in the correct cn/uid and password the access is denied. I get following exception:
java.security.AccessControlException: access denied (java.net.SocketPermission IP:PORT connect,resolve)
I know that my login name and password are correct because I was able to access the ldap via JXplorer and checked it. Could App Engine be the problem? And if so, how can I test my application when using App Engine is disabled?
Thanks in advance
you mentioned that you are developing for app engine.
On app engine you are not allowed to open a socket by yourself (your exception occurs because of this restriction.) If you want to setup a connection to your ldap you have to wrap your ldap call as HTTP and use it with the url fetch service. If the ldap is inside your company you can use google secure data connector to have a https connection from app engine to your internal network.
If you are developing for app engine, i dont think you can connect to LDAP or JDBC or anything TCP/IP, apart from what app engine offers as API.
LDAP requires sockets (TCP port 389) and AppEngine does not support sockets.
Related
What's the best security practice to follow while using PouchDB on the client-side to access a remote server?
The example on https://pouchdb.com/getting-started.html syncs with the remote server with the code:
var remoteCouch = 'http://user:pass#mname.example.com/todos';
The problem is I probably don't want the user to see the plaintext password with a file they can download -- even if that file is shown to the authenticated users only.
Please advise. Thanks in advance,
Here's a really good article regarding all things auth for CouchDB.
I've got a production server with CouchDB configured to use HTTP over localhost but external requests require HTTPS redirected via stunnel to CouchDB.
On the client I use PouchDB to maintain a local, replicated db. As part of the handshake to establish communication with CouchDB over HTTPS, the software acquires CouchDB credentials from another server - the credentials are never stored client side.
pouchdb-authentication is a good plugin, but I've found it better to handle auth personally.
Every site user should have his own CouchDB user. As #onno suggests, use HTTPS and the user's login credentials to access CouchDB. Passwords should never be available in client-side JavaScript.
This depends on your remote server. If you use a CouchDB server, you could configure it to communicate only via SSL (HTTPS), see the docs for details.
If you don't want to expose your CouchDB server directly to the internet, you could also hide it behind a reverse-proxy, e.g. an Apache server with the mod_proxy extension and SSL enabled.
Problem: I want users from my corporate client to authenticate with my web server by using their local LDAP credentials. Users have a local desktop client that can authenticate with the local LDAP server. My server and the LDAP server do not talk to each other.
I know it is possible to authenticate on a web server using LDAP if the web server relays the LDAP request to a LDAP server. (User/desktop client connects to web server, sends credentials and web server interacts with LDAP server for authentication)
But is there a way for a desktop client to authenticate with a local LDAP server and then connect to a web server sending a token that would grant access to the web server? (user auths with ldap, sends ldap response to webserver)
I am not talking Oauth, which requires both servers to talk. In this case, the LDAP server is isolated from outside contact.
The big problem here is that you should never trust the client, even if you have written it yourself. Something like public/private authentication would (probably) not work as well, since the problem is not the encryption, but making sure the message came as "OK" from the LDAP server. A rogue client could fake the OK and sign it anyway.
If I understand your problem correctly, you're looking for a way to make your desktop client talk to your web application using the user's domain credentials.
This should be easy to do using something like ADFS. If you run ADFS inside your clients Active Directory domain, your desktop client can get a token from it using Kerberos. It can then use this token to authenticate with your web application.
You will need to configure your web application to trust tokens issued by the ADFS instance in your clients domain.
ADFS may work, but it is unnecessary. You should look into using SPNEGO as it does not require a ADFS infrastructure.
Using the IBM SBT, one can easily register and endpoint to connect to IBM Connections Cloud. That way it is easily possible to access the APIs provided by IBM Connections using a local URL that is then proxied to the cloud.
Usage can be done using the provided JavaScript or by just requesting a resource from the locally provided endpoint that is connected to the cloud. While this appears to be working for the vast majority of the documented APIs, it does not for the OEmbed API.
Example: If you have a local Java App Container (like IBM Websphere Liberty Profile) that is running a testapp and has a configured endpoint to your Connections Cloud Organization, you may ask that endpoint to retrieve the users profile service document by requesting: https://localhost/testapp/service/proxy/localhost/profiles/atom/profileService.do.This will retrieve the very same resource as you would receive if you request https://apps.na.collabserv.com/profiles/atom/profileService.do directly.
Other APIs work similarly. Unfortunately the OEmbed API does not. That means, if one would request https://apps.na.collabserv.com/connections/opengraph/form/anonymous/api/oembed?maxHeight=180&maxWidth=180&extended=true&url=http%3A%2F%2Fwww.ibm.com the server returns some JSON as described in the spec. In the same seting as above, a call to https://localhost/testapp/service/proxy/localhost/connections/opengraph/form/anonymous/api/oembed?url=http%3A%2F%2Fwww.ibm.com&maxHeight=180&maxWidth=180&extended=true should return the same result but isn't. Instead the server returns an Error 403: SRVE0295E: Error reported: 403 with a HTTP Status 403.
The response is by the way the same result as one would get if he was trying to use the direct URL unauthenticated against the cloud.
Is there anything that needs to be configured in order to use the OEmbed service via SBT?
I completed all the steps of migrating from parse to my local server windows server 2012R2 deployed mongoDB and the parse server and the node.js and python on the server and of course installed the webserver role on the window.
I am now successfully listening to port 1337 for connections and I connected my node.js to the mongoDB and also accepted connections successfully to the database via port 27017. Entered my new app keys and client keys and updated them on my application. But my application has facebook login. And for sure when I open the app to login it gives me an error in the console saying "facebook auth is not configured". Ordinary user login is working but the Facebook one is not.
I think there was a way that I can add my facebook app ID to the nodejs index file where I updated all the keys. But I really don't know how to do it. If any body has experience in deploying parse on his own web server please advise.
Thanks.
I find myself in a bit of a dilemma. I am preparing to push code out to a test server (out in the wilds of the Internet) which handles user registration and authentication (using Express + Passport) for acceptance testing.
However, I would like to be able to restrict access to the test server to those users who will be performing testing. I know node does not support an .htpasswd file mechanism but looking for another way to restrict users from accessing the server even before the application authentication process begins.
All thoughts welcome!
You can restrict via IP address in your application, or the server's firewall. If you have a reverse proxy like nginx in front of node, then you can set it up to require basic authentication via an htpasswd-like file.