Which one is the best approach/method to implement security in Java EE?(JPA/JSPs)
I'm working on a personal project so I can learn Java EE and I am a little confused on how to approach the AUTHORIZATION and AUTHENTICATION process on my website.
I have different roles and I don't want certain users to access certain parts of the website. So I've been searching for docs and tutorials and etc, but everything I find dates to more than 3-4 years ago. Is there anything more recent that I should look into?
Here are some of the things I found:
http://www.oracle.com/technetwork/developer-tools/jdev/oc4j-jaas-login-module-083975.html
Any help would be greatly appreciated!!! :)
Spring Security. Although it is branded as Spring, you might find it useful for web applications; do note that you don't need to write a Spring app to use Spring Security.
If you wish to stick to JAAS, I would suggest using one of the container's login modules, just to get started, before you attempt to write your own login module. Be forewarned that you might end up writing one, if the container supplied modules do not meet your requirements. And, there is a good book on JAAS to help you understand it in detail.
Moreover, take a look at Servlet spec 3.0, to see how annotations can be used declare the roles (#DeclareRoles, which came in servlet spec 2.5) in the servlet itself, before defining what roles have access to what HTTP method (using #RolesAllowed). You can also employ annotations like #DenyAll and #PermitAll, to permit or forbid access to all users. #TransportProtected will ensure that the HTTP method is accessed over HTTPS. All one needs to do, is to map these roles in the source code, to actual roles in the JAAS realm; this often done using a container specific descriptor file.
ADDENDUM
Since you are using JSPs and not Facelets or any other technology for the presentation tier, you might be interested in the JSP tags offered by Spring Security. It is much cleaner that maintaining all of the authorization metadata in a humongous web.xml file.
As far as JPAs are concerned, well, the underlying access to them is usually enforced at the servlets or EJBs. Of course, you can build in more programmatic security, based on your needs - using entity listeners would help in this process as you would be able to intercept load, update and persist operations (if you are that particular, but for the most part building security before your business logic is executed usually is sufficient).
And oh, take a look at JBoss Seam (and Seam security), for it is a complete application development framework built on Java EE.
Something more recent than JAAS is the Spring Security framework. It supports JSR-350 (EJB 3) and thus would work fine in Java EE.
I worked on a Java EE application recently with JAAS. It's pretty current, you can check it's home page at Oracle.
It works with roles, authentication, etc.
You can use it in JBoss and Glassfish, probably the rest of the ASs too.
Spring security tutorial https://www.packtpub.com/spring-security-3/book. Highly recommended.
Related
I'm currently working on a web application based on Java EE 7, PostgreSQL and the application server GlassFish 4.
I need to implement a form based authentication, and to secure some URL knowing that :
the users and the roles/groups (whatever they are called) are stored in the database.
I wanted my application to be as "standard" as possible (i.e I am currently using JSF and JPA, and no other framework like spring, struts ...)
After some research, I found that Java EE provided a standard authentication mechanism called JASPIC. So, I focused my research on JASPIC and I read multiple Stackoverflow Q/A and those articles written by Arjan Tijms (It's almost impossible to find a Stackoverflow Q/A related to Java EE without one of his answers or comments, thanks to him by the way) :
http://arjan-tijms.blogspot.fr/2012/11/implementing-container-authentication.html
http://arjan-tijms.blogspot.fr/2013/04/whats-new-in-java-ee-7s-authentication.html
http://arjan-tijms.blogspot.fr/2014/03/implementing-container-authorization-in.html
My question is : will JASPIC allow me to do what I need (form authentication + URL restriction with roles) and is it worth the effort to use it ?
What I mean is : it's perhaps safer and easier to use another mechanism.
Arjan Tijms also says that whether or not using JASPIC is "a kind of chicken-and-egg problem" and if JASPIC is safe to use (It doesn't create more problems than it solves), no matter the amount of code I need to write, I really want to be "one of the first chickens".
I'm using JASPIC for my authentication, but JASPIC has one limitation you need to contend with (if you want things standard). You're limited to having no dependencies outside of the Java EE 7 API. This means access to JDBC resources which require a driver is not a capability that is explicitly stated in the standards.
In my OpenID Connect implementation I used Google as my secure store, which also presents me with the Google login form. That is a larger example of using JASPIC though.
For yourself, you can expose an EJB to the global namespace and use InitialContext to get the EJB. There'd be some code duplication in that you have to copy the EJB remote interface code in two places and ensure the serialVersionIDs are the same on both. The EJB can be used to connect to the JPA resources to get your authorization data.
Use EJBs, because the other two options you may think of are REST and SOAP which would be exposing something on your web ports and would require some extra configuration to prevent unauthorized access or require they be placed on a different system.
A simple JASPIC implementation I created in case you want to learn is the HTTP Header JASPIC module which is intended for integration with more complex systems like SiteMinder.
I do no know JASPIC but may I suggest you take a look at the shiro framework
It let's you do pretty much everything you need based on your post with minimal configuration.
For Form based authentication and authorization, you need JAAS. go through follwing url-
linK
I am currently using Oracle ADF (which is an end-to-end Java EE framework) for building my web applications and GlassFish 3.1 as application server.
The latter supports JAAS (declarative inside its admin console). So, I have created a security realm and mapped them with the roles declared in a configuration file and use JAAS to implement the authorization and authentication security features.
Everything fine, until now! This past weeks I have been researching on Java EE security.
What I've found is that JAAS is good enough if you stick with "basic" security. Moreover, it seems that JAAS (as part of the Java Security Framework) was meant just for Java SE (but since Java EE is built on Java SE, some of it’s modules are being reused, such as LoginMethod and Callbacks).
Then, I've found many posts about JASPIC, finding out that it can be implemented only by a programmatic manner (not a problem) and it's not yet fully supported by app servers vendors, and tried to make a comparison between both. Even if JASPIC1.1 release had resolved some issues, like:
The container will however not fully remember the authentication. The
SAM is still called at each request, and the SAM still has to
re-authenticate
(it doesn't sound so good to me).
Then, I've passed on looking for integrating some security framework. The most famous ones seems to be "Spring" and "Shiro". Of course each one of them has it's own characteristics (may be the first is more suitable on a specific situation while the second in another). What's more important to me at the more are:
Authentication
Authorization
Session Management (and possibly, encryption)
But, everywhere I found contradictory conclusions. The result: I'm more confused now then before searching.
I am just a novice in topics like security, and moreover I am a developer (I have stuff to implement), so it's kinda hard to keep up to date with every new release and the progress on security seems to keep going on every day galloping.
I'd like some facts based on personal experience if possible. Every hint or suggestion is appreciated. I want to be sure I'm confident before taking the implementation step.
JASPIC is the one technology that being a part of Java EE integrates really well with it.
The fact that JASPIC authentication modules don't automatically remember a session is an advantage too as it makes them suitable for stateless applications too (think APIs such as JAX-RS). When you authenticate and do want sessions, then just put the result (username + groups) into the session. Then at the start of each "validateRequest" method do a quick check if there's anything in the session and if so give these to the container again. No need to authenticate from scratch and certainly no need to remember any password!
Shiro and Spring Security are very full featured frameworks. You can barely compare that to JASPIC which is very low level and basic. Both Spring and Shiro don't perfectly integrate with Java EE. Spring Security is often said to be more complex than Shiro.
Hope this helps
The Servlet profile of JASPIC requires that the configured (for the app) Server Authentication module(s) (SAM) be called on every request; exactly so that the SAM will be able to manage authentication sessions (should that be desired)
The profile also supports the case, where a SAM is configured to perform authentication, but then wishes to delegate authentication session management to the encompassing container, which is enabled by the used of the registerSession callback property.
Also as noted by Mike Braun, the profile also supports a stateless mode wrt to authentication sessions, and is fully integrated with the container authorization system; such that JASPIC authentication must occur when the target request is covered by an authorization constraint (such as would be defined in web.xml or by use of the ServletSecurity annotation).
The JASPIC defined Callbacks and the container provided Callback handler, allow a portable SAM to set the container caller principal, to consult the container's user registry for password validation and group assignment, etc.
i am going to build a SSO infrastructure which enables one time log on for some sites.
do you have any idea how does it work,.?
i mean the architectural and how all those sites comunicate and ask if an user is authenticated already, is there any special protocol for it,.?
i am familiar with Java and PHP programming, which one is the best suites the SSO implementation,.?
thank you for your response,
Whatever you do, don't attempt to write your own library unless you have a background in strong cryptography, browser exploits, cookies, and session management. (If you did have a background in these subjects, you likely wouldn't be asking this question, so I will try to give you some more useful advice.)
For Java, there are two big security libraries available: Spring Security or Apache Shiro:
Spring Security is extremely mature but hyper-flexible. It almost does too much for simple applications, but if you're already using Spring, it just makes sense to use Spring Security. It's chock full of features and can do some awesome things if you need highly granurlarized security. It has integrations with CAS (An SSO server) and can authenticate against LDAP, JDBC, and many more. Spring Security is 'declarative'; it relies on annotations and runtime AOP to inject authorization checkpoints into your app.
Apache Shiro is much simpler: a servlet filter and a .ini file and you're up and running. It has really simple SSO and remember me features that are much easier to implement than spring security. The API is programmatic, rather than declarative in nature; which I think is simpler, but makes your code tightly coupled to the Shiro library.
Either route will requires you to stick to mainstream Java patterns and good programming practices. Poor programming elsewhere where nullify any security framework.
I'm trying to understand how the JAAS principal propagates to the Business/EJB tier from web tier.
I've read that the if the roles/realm is configured in login-config & security-context of web.xml then the servlet container will also transparently pass the authenticated principal to the EJB Tier.
Two questions
1.) First & more importantly is that true ? Without any intervention from the developer !
2.) And secondly any idea how that works under the hood.
yes it's true. that's generally the point of ejb, to take the "hard" stuff out of the hands of the developer (e.g. security, transactions, robustness, multithreading, etc.)
it's implementation dependent. i know that in jboss (at least 4.x and before), remote method calls used a custom serialization protocol which had an additional Map of arbitrary information which could be sent along with the request. in this was the auth info as well as other stuff to support clustering. for local method calls i believe they use stuff like ThreadLocals.
There are various "context" pieces of information that get propagated in EJB calls, once you get inside the EJB layer and start doing EJB-EJB calls then Transactions would be an example. Some containers allow you to create your own such context objects too.
Thread-local storage can be used within a process, but generally just assume that the container is in charge and can do the right thing - the actual technique is implementation specific.
Regarding your first question - yes.
Regarding your second question - are you familiar for example with EJB3 interceptors?
The container create proxied objects with "interception code" for the beans,
and in addition the container can track other annotations on the methods and the bean class, for example, to detect the #PostConstruct annotation.
Using the role definition, it can check the configuration (either login-config.xml at older versions of jboss, or standalone.xml in JBoss AS 7 at standalone configuration) and understand what is the definition per each role.
JAAS is used in order to provide you abstraction layer over authentication and authorization.
One of the concepts behind JAAS is login module - it provides you "protocol specific" code that takes care of the actual authorization and authentication.
For example, I'm using in this way Krb5LoginModule to use kerberos.
The Principal propagates to the EJB tier from web tier is configured through the login-config in the web.xml as you had surmised for the most part.
How it is implemented is implementation dependent. The user/group data is also implementation dependent and is configured as part of the application server.
However, one of they ways this is done is through an implementation of the JASPIC provider which is a standard way of obtaining the Principal. Using this allows you to have a different authentication path compared to the standard form login, basic authentication or certificate authentication provided by WEB-INF/web.xml but it is a little bit more work.
JASPIC authentication paths allow more complex scenarios such as header based authentication or two-factor or OpenID. The user database "usually" does not need to be tied to the one in the application server. I say "usually" because WebSphere Application Server ties the authentication to a user configured on the server.
I am wondering what all options or ways do we have in a Java EE 6 web app, to log in users? With this I mean, saving their data (id, username, ...) while they are using the app.
I know this data is stored in a session while thy are using the site, sometimes in cookies or even the URL.
But what I would like to know is:
What is the most common approach in a Java EE 6?
What would be the most recommendable way?
What do you practice and what do you prefer?
What other options do we have?
What would be the safest?
What would be the most recommendable way?
On Java EE 6, that would (in my opinion) be using container managed security with a Realm pointing to a SQL database.
What do you practice and what do you preffer?
Before Java EE 6, I used to prefer a homegrown login mechanism because I'd like to have full control over the login. Most containers namely doesn't allow filtering j_security_check requests. Since Java EE 6 it's possible to do a programmatic login with the new HttpServletRequest#login() method, so that disadvantage has gone.
What other options do we have?
Well, I already mentioned two major ways. Apart from some frameworks like Spring Security, there are not really other options. The container managed security in turn offers several ways to do the login such as HTTP BASIC authentication (which just shows a browser-builtin JavaScript-like login popup), form based authentication (using a HTML form submitting to j_security_check) and the new programmatic login.
What would be the safest?
All are equally safe. The safefy in practice depends on your own code and configuration settigns.
try to use some framework, like spring (spring mvc will automatically inject the session data which include log in info).