I'm charged with building an app health monitoring system, and one of the requirements is to check both if our various java services are up and if our reverse proxy is up. The reverse proxy is a .NET application that gets a user's AD Groups and passes them along to our apps via a header for monitoring/security reasons.
Obviously the rinky dink input and output stream http request isn't enough, but I haven't found information or guides about client-side NTLM authentication for Java.
I'm guessing there's a library (probably Oracle or Apache) that provides a handler that can do this, but I have come up empty trying to find it. Please help.
Great code and context can be found here, for client side.
http://davenport.sourceforge.net/ntlm.html#appendixD
Related
I have a Java Spring driven REST API server connecting with PostgreSQL database and a Spring Web Server in Java that is serving content from the REST API to the client using JavaScript (now browsers, but in the future also mobile apps).
I've read a number of articles and topics how one can secure a REST API, but I haven't been able to make a final decision yet. I don't want to have Basic Authorization, because it doesn't make sense as I would need to store credentials in JavaScript that can be easily accessed and read by anyone entering the webpage and developer console. I'd like not to show any credentials to the end user so I can't keep them on the client's side.
I've read a lot about JWT and almost decided to implement it, but I've heard it has some drawbacks and haven't been so sure since then if it's the option I would like to choose. I know there is also oAuth 1.0 or oAuth 2.0 but I don't know if I want to have something this complicated. I would also like to store hashed user credentials in my own database in order not to be depended to any other credential providers like social media or Google.
Now I'm making another layer on my web server as a proxy hoping that it will allow me to authenticate user on this proxy level using Spring Security and having some kind or cookies or something to authenticate, but I'm not so sure if its doable this way and it increases the respond time, adds complexity and needs me to write controller methods for these endpoints. My architecture now is of the following:
Client (browser) -> Webserver -> REST API server -> db
I've also denied all external connections and allowed only localhost access to REST API on tomcat level so that I'd have to implement the security level only on the web server allowing free information transit between the webserver and REST API as it is not reachable anyway.
Web server and REST API are on the same server running as Tomcat instances.
I'm also not so sure if this kind of architecture will allow me to authenticate mobile app clients through the web server.
I would be very grateful for any piece of advice you would have for me in this matter. I'm not so experienced in security, so I'm a bit lost what I should do. Does this kind of architecture any sense or should I simply ask REST API directly from any type of clients, be it a webpage or a mobile app from different IPs and secure Rest API only? And if I want to secure some subpages of my webpage or parts of mobile app should that be an completely other layer?
Thank you for your help.
You have already gone through OAuth, JWT tokens etc. If you don't want to use them,then you can create your own token based authentication system.(say 'TokenHandler').
How this TokenHandler will work ?
TokenHandler will be like a gateway server i.e your every REST API request will route through this server application. So you will address your confusion of mobile and web application call with a authToken in header. Main responsibility of this server applciation is to accept the token and validate against the database where all token details are maintain. This DB will have information regarding timestamp when token was last used to validate, to decide your validation rule .
How Token will get generated ?
Token can be any random 64 digit alphanumeric string and will be generated and updated in DB during every single login activity. Login webservice returns this token in response body.
What can be rules for validation ?
It can be depending on your business logic. I preferred to keep active session window of 15 mins. Means if you access the webservice you will get active window of 15 more minutes. If you didn't access any service for 15 consecutive minutes then from 16th Minute you will need to login again to access further calls. This part can change according to requirements.
How client side will handle this ?
Client side will store this token and pass this token with every request call. Token Handler will validate and redirects it's request to the application server . So your one token handler can be used to server authentication of multiple applcation servers. This you can achieve by application end point identifer.
I will like to discuss further if you have any questions or suggestions .
Use API Gateway Architecture Pattern for your use case -
http://microservices.io/patterns/apigateway.html .
The API Gateway (The webserver in your question) can act as single entry point for all desktop/mobile clients. You can use either session cookies or jwts to authenticate clients at gateway.
With respect to authentication between gateway and micro services, and between micro services, i would suggest mutual ssl - https://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication. If you are using spring boot, this might help - http://www.opencodez.com/java/implement-2-way-authentication-using-ssl.htm
The problem with IP white-listing approach is that - it's not well suitable for cloud architecture as the IPs might change with every server reboot. Even if you are using dedicated IPs, you should be careful to secure the communication with SSL/TLS, else attackers can easily sniff your traffic.
I am trying to build a Spray REST Web server for my mobile application on android (Eventually Iphones too). Currently, I am wondering how to determine from the server side which user is making REST Method requests. After some research I am understanding that android's SharedPreferences or an OAuth protocol can be utilized to handle user authentication. Still I am unsure how to create the entire picture of "This user is requesting some information". The message responses will be in JSON text, should the request's be in JSON as well?
I greatly appreciate all of your help, eagerly awaiting responses.
Currently, I am wondering how to determine from the server side which user is making REST Method requests.
The most adequate way to do this is to add auth layer to your server. There are many ways of how exactly you can do this, depending on security concerns you have to deal with.
Here is the list of auth schemes I would be looking into first of all:
Http basic auth (most simple one, stick with it if you can)
OpenID or OAuth (harder to implement, solves some problems that are out of scope of simply authenticating user. Note: OAuth is about authorization but can also be used to do authentication)
home-gown auth (may be implemented on different network layers, lots of options here. Do not recommend going here unless you really need to).
You can send more info from client side when user send request, you include unique info (Android ID, Ads ID for example)
server.address/request?command=abc&uid=UID...
. Another way is read IP address of the user and manage it by session.
I'm developing a Java application that will display Instagram content. It's for an installation, and will only ever authenticate as a single user. I'm trying to keep my OAuth consumer code as simple as possible.
Twitter offers a "single-user" OAuth implementation that seems quite a bit simpler than the standard "OAuth dance". Is there anything analogous for Instagram?
If not, are there any other shortcuts to getting up and running with OAuth + Instagram? I'm using Apache HTTP Components (specifically, Fluent, to ease asynchronous communication) and looking into using OAuth Signpost. However, the path to Fluent+Signpost isn't immediately obvious...
I was barking up the wrong tree. Turns out I don't need authentication for the requests my desktop application makes, only need to pass the client_id.
There's a limit per hour on the number of requests per client_id; for applications with multiple users, it makes much more sense to authenticate so that limit shifts to per-user (via OAuth access token), but for my single-user single-install application that's not necessary.
We're trying to upload a file from a flex client to a Java EE app.
In a full HTTPS environment
Java EE server is JBoss 5
Using BlazeDS 'Custom' authentication (username and password are entered trhough a flex form)
Using BlazeDS per session authentication
In regular AMF calls, we can access user principal and use role mecanism.
However, in our upload servlet, we have no access to user principal.
request.getUserPrincipal() // returns null
How to fix this ?
A while ago a guy commented on a blog post of mine that https + flex + firefox doesn't work:
have you tried uploading a file in firefox via https? Well, don’t bother, it can’t be done! Adobe blames it on firefox and puts their head in the sand. Read the teeth gnashing and ridiculous claims of Adobe here:
http://bugs.adobe.com/jira/browse/FP-201
Ultimately they threw up their hands and said it couldn’t be fixed, and, although said ‘We understand that this is a serious issue and are committed to resolving it’ suggested that either you:
1) Send the file to your server in a different way
2) Find another form of authentication
This may no longer be the case - register and see if the linked bug is still unresolved.
Also - this might not be your exact issue (at least not yet) - I'm just giving pointers.
From your post, and since I haven't used BlazeDS, I can't tell whether you're running into this issue specifically, but it sounds to me like you are --
Take a look at your server logs, or try using a Web debugger like Fiddler (you can tweak it to reveal HTTPS traffic in clear text), and you'll see that Flash blocks custom HTTP auth headers with FileReference.upload(). Why it does, I've no idea, but there's no workaround I know of, other than crafting something or your own manually.
I'm working on a server written in Java, and a client (a desktop application written in .Net) that runs on Windows machines on the same network. I would like to have some basic authentication so that the server can determine the username of the user running the client, without needing the user to re-enter their Windows password in the client.
Is this possible, and what's the simplest way to accomplish it?
I had a look at some of the available APIs, it looks as though the org.ietf.jgss package in Java, and NegotiateStream class in .Net, should probably be able to talk to one another to achieve this - but I keep hitting frustrating error messages I don't understand. I thought I'd check if this is the right approach, if so I'll post a separate question with more detail about the errors in question :)
The approach is the right one. Notice a number of things, though:
this will have nothing to do with "Basic Authentication" (in http)
.NET will try to use the SPNEGO GSS mechanism. See the Sun documentation for proper support of this mechanism.
your service will need to incarnate a service principal. So you need to create an Active Directory account not only for the user, but also for the service, and you need to put the service's password into the Java keytab.
If you're using Active Directory, I think the Spring LDAP module can offer you a nice way to access credentials.
Not being familiar with the GSS mechanism. I would suggest a shared key mechanism used in passwordless ssh.
This open source library http://spnego.sourceforge.net has exactly what you are looking for. It implements an HTTP Servlet Filter on the server so that your web-app can call request.getRemoteUser() to find out the username.