I am using AngularJS along with REST API on Java EE 7 backend. The project is deployed on a Wildfly application server and I have some questions regrading securities:
To Encrypt/decrypt data I am using CryptoJS to encrypt and decrypt on server side ( Java ) but apparently we have to send the passphrase in clear, the cipher and salt are only encrypted. My question is why the passphrase is clear text ? it should be secret and then encrypted as well no ?
For the REST API, what is the standard to use for Java EE 7, HTTP security header (basic-auth) ? Json Access token ? and how it really works, where to store user session/token, on a cookie ? I just want to know how to do it with Angular.
Maybe I can use the classic JAAS with form-based authentication and then having request.login() on server side to be authenticated then my EJB will be all protected by @Role.
What is the way to protect pages in AngularJS ? For the moment I am using the web.xml and putting the URL patterns, maybe there is a better way ?
I already found lot of examples like this:
AngularJs and Jboss and JAAS ( omnisecurity )
how to integrate angularjs and java jaas based authentication?
Some users mentions this:
* index.html page should contain token inside html to avoid CSRF
* token shouldn't be stored in a cookie storage
* Each request should be signed with header param
* Server should validate every request by passed header
* If cookie usage is a must you should validate referer in order to prevent CSRF
But there is not concrete example on how to implement this, especially the CSRF.
As soon as you are sending a key (passphrase?) in clear - the encryption is useless.
To achieve reasonable client-server security, use the HTTPS. Simple, effective and much more secure. Generally it is a bad idea to encrypt on the web application side, as the user or a 'man-in-the-middle' can retrieve or modify the key and data.
The different case is end-to-end security, when the client encrypts, posts encrypted data and they are stored/processed as they are, with the encryption key available only to the user. If it's not the case and the service needs the data for further operations, the HTTPS is the way to go.
Effectively you listed you options. This is your decision. Every option has its pros and cons. Basically - if you're talking about (REST) services, it shouldn't matter what technology is used.
For the REST services called directly from the browser I'd omit the basic authentication (otherwise user would get the pop-up authentication window)
You can use the JWT token (signed by the application secret, just add some expiration date), but then you cannot 'logout' the user, just wait until the token expires. The advantage is, that the token is 'self-sufficient' and you need not to worry about the session management. The client sends the JWT token in the Authorization HTTP header, you just decode it, validate and then you can assume the identity from the token.
Another option is a session token (cookie or sent as an Authorization header), where you need to manage the sessions (store the tokens, clear the token out on logout, ...). Using the app server session cookies makes your services unusable by other applications (still a question - do you want/need the services to be reusable by third parties), but you achieve built-in authorization (JAAS , Roles, ...).
Indeed, this is a way how you authenticate and authorize the user and issue a token (jwt, cookie, other...).
The default web authorization should be ok.
Still - keep it simple. According to my experiences the static resources (web pages, images, scripts, css) should be static and it shouldn't really matter if they are publicly available. The important is the execution (operations, data, ...) are exposed as the services and that's the point where you do proper authentication and authorization.
Have fun