Single sign on - Django to a java servlet - java

I have a django front end which the client will log into. media streams selectable from the django ui will be served from a wowza server. The wowza server needs to know that the user has permission to view the media resource.
Wowza supports java packages so I can insert user authentication into my wowza app to control access to media resources.
I own/control both servers, so I can configure a secure connection between them.
I think i should be looking into something like Oauth to pass credentials, but I am not certain as I have never looked into how to pass user authentication between two web services before.
So I think my question is: Is Oauth the appropriate mechanism to use? and if so, whats the basic requirements in terms of the django package and Java pacakge to use?
Or, is a single sign solution like this one more appropriate SSO (Single sign on ) in MVC

What do not try RemoteUser backend to authenticate and use http info from REMOTE_USER variable?

Related

Securing REST API in JBoss

I'm developing a RESTeasy JSON API under JBoss-As 7.
I have another separate web-server.
I am developing with JAVA on server-side, and on client-side with Javacript, JQuery, AJAX.
So, I have 2 distinct *war*s, let say they can be accessed as following:
https.//localhost:8443/services
http.//localhost:8080/web
Now I want to secure these two guys; RESTeasy API and web-server.
Let me tell about my structure:
I keep the users in DB with username-password. These are the only users for now.
I have a login page to authenticate my users (I don't want http basic auth popup and any workaround about that)
The clients of REST API are browsers (not web server). The static page is load, and then some other dynamic things are load through REST API, calling within from browser using JQuery, AJAX, whatever.
All communication can be through SSL/TLS, no problem.
For the future, scalability (clients other than web-browsers, ability to authenticate with social network logins, etc.) should be in mind.
My scenario is as following:
Client is browser.
Client wants to access a web page web/aaa.html which is restricted to authenticated users.
Client is redirected to login page: web/login.html
Client filled the FORM and sent to ... either,
a) to the rest-api, or
b) to web-server,
not sure (So, here you have an implicit question).
But in any case, what a or b should do is the same:
Check username-password. Let say they are checked and the user is authenticated.
From now on, I should have got these two things at the same time:
1- Client is authorized to navigate the restricted pages.
2- Client will be authorized on REST API calls.
So, I need these 2 things at the same time happen, after authenticating in login page.
I have read lots of things, about authorization in REST API, with tokens, keys, etc. and yes I also have heard about Spring Security, Apache Shiro, etc.
And yes, I do not want to implement a new security framework by own and I will use one. I imagine that some framework can produce/check tokens etc. for me.
Before Spring Security and Apache Shiro, I want to know about resteasy skeleton key JBoss module.
There are these sources:
https://github.com/resteasy/Resteasy/tree/3.0.1.Final/jaxrs/examples/oauth2-as7-example
http://docs.jboss.org/resteasy/docs/3.0-beta-2/userguide/html/oauth2.html
But, they didn't seem to me very explicative, and also I am not sure if they are what I need.
Is there someone who knows how to configure skeleton key (or in general JBoss App layer) and give me useful example to achieve what I've described, please?
Or, could you give me some other advice/example to achieve my goal, especially noting that my question is about "how to implement"? I don't see where to begin.
Thanks in advance.
For securing REST Services, We can use following framework
OAuth (Open source - RFC6749)
Apigee

Security with Play! from Outside Application

I am working on writing a private REST API with Play! that I will make calls to from a mobile application and I am confused about how to keep it secure.
When working through the Yet Another Blog Engine example in Play!'s documentation, I worked through their authentication example, and it deals with logging in through a browser. From what I understand about Play!'s Secure module, it helps with browser sessions. Additionally, every StackOverflow question I have seen has been involved with an administration module on the web and the questions have been pertaining to sessions as well.
Does the Play! framework have any built in mechanism to prevent session hijacking?
Enforce Https routing for login with play framework
My current understanding of how the security should work:
The mobile app "logs in" to the web app and obtains some kind of token
With each subsequent call the token is appended to the end of the API call
If the mobile user "logs out" or the token expires, the web app removes the token
Every API call uses HTTPS in order to maintain security
Is it possible for me to make an HTTP request from the mobile application to the web application I create using Play! Framework while keeping it secure?
Am I approaching the whole situation incorrectly?
This is the first Play! app I have created and this is the first time I have used Heroku. I am not too far in that I would be opposed to switching to something else if it were significantly easier/more efficient/better suited to solve this problem.
EDIT: Also, in Play!'s YABE tutorial, it seems like they check the password in plain text. Just from a general standpoint, how is that not a security issue?
EDIT 2: I have looked over OAuth provider information and it seems to solve the problem. My only apprehension with it is that v2.0 has known security flaws and v1.0 seems complicated to implement for a situation where all I need is a secure connection between a mobile app and a web app. If I were to make every call require SSL, could I make each Play method just take username and password as parameters and disregard OAuth completely?
Your example of having a mobile application authorize itself with a web application is achieved with an authorization framework like OAuth. This allows the web app to let the user login then issue an access token to the mobile app for making requests as that user, without the mobile app having to deal with the user's password.
Have a look at an OAuth provider module for Play. If you Google, you might find an OAuth client module for Play, but that's for the other side of OAuth, allowing your web app to authorize against a 3rd party provider. You'd then use an OAuth client library in your mobile app to deal with acquiring an access token.
It could even be a generic Java libary for OAuth - the Play 2.0 documentation for OAuth states that it hasn't provided an OAuth 2.0 module because it's simple enough not to even need a library. However there are a few Java libraries available.
Here's a project where somebody's put together some OAuth provider stuff with Play (referenced from this forum post):
https://github.com/mashup-fm/playframework-oauthprovider

Making a web service, which approach?

I have made a Java EE 6 application where a user can browse a set of questions, add new questions and so on. The user can optionally log in so that he/she gets "credit" for adding the question or reporting it as bad.
Now I want to make a iPhone application where the user can do pretty much the same. So the answer is web service I assume. I have not worked with web service before but I see there are at least to alternatives: SOAP and REST.
Which one should I choose? I want the user to be able to log in from the application as well a as browse the questions in the database...pretty much many of the actions you can do on the web site.
I don't know much about the security and overhead they introduce.
Also I want the user to be able to retrieve the list of questions thorugh the web server and have the option to save it, so he/she won't need to have internet unless he/she wants to update it. Can I achieve this with both web services?
REST has less overhead than SOAP (WSDL contract, XML messages, supporting frameworks) so when the client is a mobile device REST seems more suitable. You could use JAX-RS (Jersey) to easily create REST services on the server side. The client request consists of the url structure and/or parameters like http://yourserver/questions/view/342 (to view question 342) or http://yourserver/questions/search?q=REST+vs+SOAP (to search for questions about REST vs SOAP). The response can be anything you want, but XML or JSON is pretty common.
Choosing REST means you will be leaning heavily on the HTTP protocol. For security a common approach is to use HTTP Basic authentication in combination with https. Basic authentication means you add an 'Authentication:' header to your HTTP request containing a Base64 encoded username:password pair. Note that Base64 does not encrypt anything, it just obfuscates. To avoid eavesdropping you need to use at least https meaning requests are encrypted using the server's public key. These requests can only be decrypted with the server's private key. To use https you need to set up the server with a certificate. If you want to avoid warnings about the certificate being 'untrusted' it needs to be issued by a recognized SSL certificate provider. For testing you can just generate it yourself.
Finally you asked about saving a list of questions for offline usage. This is a concern of the app, not of the service. To do this you need to store the retrieved data on the device and access that data if the device goes offline. I am not an iPhone developer, but I can imagine you could use a flat file or some lightweight database to store the data. When the device is offline, the app component that retrieves data should switch from network access to local storage access. Also some app functionalities like adding a question might need to be disabled. If you don't disable these, you would need to temporarily store any data entered by the user and send it to the server when the device comes online again. This could be a bit tricky to get right so my advice would be to leave this for later.
You can take a look at this previous SO post for some guidance. I would recommend using REST, it seems to be less messy than SOAP and Java has support available for it as shown here.
Through the use of annotations, you can simply created a facade to which users will connect. In turn, this facade will call the relevant logic which I am presuming you already have.
Well on a simple search REST vs SOAP, you will eventually get to this
There are plenty of other articles and even in-depth research papers, so it's only a matter of - do you really want to get serious with your research VS not really
Good luck!
Short answer: Yes, you can achieve that with web services.
Web services are only a facade to your system - they can expose (or not) any behavior you want to. If you have security concerns, you'll have to approach them anyway in both methods.
Personally, I'd use a RESTful approach as its usually simpler to implement and use. From Wikipedia:
A RESTful web service (also called a RESTful web API) is a simple web
service implemented using HTTP and the principles of REST. It is a
collection of resources, with four defined aspects:
the base URI for the web service, such as http://example.com/resources/
the Internet media type of the data supported by the web service. This is often JSON, >XML or YAML but can be any other valid Internet media type.
the set of operations supported by the web service using HTTP methods (e.g., GET, >PUT, POST, or DELETE).
The API must be hypertext driven.[11]
So you'd have a URL, say http://mywebsite.com/users and perform HTTP actions (GET, PUT, etc) on them. A GET request on /users/17 could return user 17, for instance, while a POST request on it would update said user.
As for login, when your users "log in" you would call a GET method that sends username:password (probably encrypted) and returns a login token. Every time the user executes an action, you would send said token with the request as an additional parameter.

App engine authentication

I am new to appengine. I will write application which consist of two parts.
1) Core written in app engine with REST interface for clients.
2) Client application written in J2EE on my other (not appengine) server. But here, client may use any other technology (android, swing etc.)
I dont know, how to handle authentication of users in this schema. I think that I am in the middle between standard login and installed applications.
The simplest solution that occured to me, that the client will request username+password, pass it to appengine application via https and it will authenticate.
But dont know how to synchronized the login with client app, because it will need also data from google applications...
Is there any solution or pre-prepared facility in Java how to handle this?
Thanks
You probably want to use OAuth for this; client login or using username+password is not a good way to do this, and informed users will be -- or SHOULD be -- hesitant to give away their passwords. There is a page for using OAuth within AppEngine applications written in Java which may be of use. There is also some support for Oauth in the GData client library for Java. The OAuth in the Google Data Protocol Client Libraries document may help you to understand how to use those features.

Username in HTTP Header for SSO

I am looking to add single sign on (SSO) to one of my web applications. I don't want anything heavy at the moment, I just want to know the userId of the logged in user, without the need for them to enter a username.
The web app is an internal application, so I can guarantee they are coming from a Windows PC etc.
I have looked at jCIFS, but this doesn't seem to be supported any more, and recommends a commercial product.
I have also looked at WAFFLE, but I am building SSO for a playframework application, which does not use a Servlet stack, so I can't make use of the SecurityFilter. I have tried to make sense of the WindowsLoginModule, but couldn't really understand what I had to do to implement it.
Is it possible to just get the username from the HTTP header, or does it require some negotiation first before it will post the header?
You want the windows user to automagically login to your intranet webapp. So the user accounts would sit in an active directory and the usual microsoft way would be to use a protocol like NTML oder Kerberos. Applications are generally advised not to use NTLM, although there are enterprises still using NTML (and jCIFS) for SSO.
A quick search on Kerberos and Java showed this article. It seems to depend on the Java EE stack (JAAS).
For a more stripped down approach: Usually, you cannot sent the username in a http request in a portable way. With ActivX you could do:
var wshshell=new ActiveXObject("wscript.shell");
var username=wshshell.ExpandEnvironmentStrings("%username%");
On the server side, you can parse the http header and extract the username with your technology of choice.
Well, security doesn't matter in your playframework application?
Why don't you use long-living cookies?
Hope it helps!
In an intranet context with ActiveDirectory and workstations registered in the domain, the HTTP SPNEGO Negotiation support is the best option. But it requires specific skills around ActiveDirectory and Java Kerberos implementation.
Spring Security provides implementation and documentation to set it up. But Secure.Security is not designed to support token-based authentication like HTTP Negotiation. So using Spring Security will require a specific integration module.
Other options are OpenID and shibboleth but both requires a dedicated server, which can be configured to do SPNEGO itself. Thanks to available Play modules, integration in your application will be easier.
The only way to get the username in an HTTP header without client-side complex and unsecure/unreliable tweaks is to use an authentication proxy between browsers and your application server. Most of these proxies also support Kerberos SPNEGO as authentication mean.
Non-heavy answer
It sounds like it should be possible to get your ops team to implement a Group Policy which will send the logged-in username down the wire as an HTTP Header.
Otherwise, you're correct in your assumption that there is some sort of negotiation "dance" between IE and your server. See here. Perhaps you can fake this dance in your Play code.
Heavy answer
I know jCIFS and this example uses servlets and filters, but the important bits of code can be extracted and a custom Play Authenticator can be built (I can paste a Scala example override of play.api.mvc.Security.Authenticated , but your answer is tagged Java). You only need the request headers (not body) so it should be doable in an authenticator.
PS jCIFS seems to have had an update since your post, so I'm presuming you'd reconsider using hacking it. I'm wary of unmaintained libraries too, but sometimes they just reach a maturity and stability which alleviates the need for any more updates.
Active Directory uses Kerberos, so all logged in users should have a kerberos ticket.
A fast google found this:
https://blogs.oracle.com/wyllys/entry/kerberos_web_authentiation_with_apache
If you want the windows logon details, I think it's your only option.
You can try to use Shiro for enabling SSO in your application.
Shiro id independent of the servlets and since your framework does not support Servlets you can very easily go for Shiro.
You can create a Realm where you define the hashPassword.
You can configure the username and the hashPassword and ask the shiro to authenticate your user with the hashPassword.
You will then assign role for the user which will serve your purpose of SSO.
You can authenticate user for more than one application and hence when user logs into another application the shiro has already authenticated you and hence it will straight away log you inside the application..
You can go through the shiro documentation(exhaustive and you should be able to configure it on first go) from the following link:-
http://shiro.apache.org/
It provides you many out of the box functionality for authenticating and authorization along with security and Cryptography modules.
The username isn't sent in the header. Even if it was this shouldn't be relied upon as a savvy user could fake the values.
If NTLM would be a valid option for you Jespa might be a good alternative to JCIFS. Jespa (unlike JCIFS) supports NTLM v2, among other things. The limited version of it (up to 25 users) is free.
You can always get any header from filter. See javadoc for HttpServletRequest.

Categories