4

I'm new to Java EE development however I'm going well in it, I'm a bit confused with the security part of my application.

I have read a few articles on how I can implement JAAS security in my Java EE web application. This is what I read & understood, all he others were unclear: http://uaihebert.com/user-login-validation-with-jaas-and-jsf/

The example is great and all but it configures the JBoss server, Im not using JBoss and I'm not intending to. If I were to use JAAS do I need to configure the local web server I'm running (developing) on? Perhaps there are some things I don't really understand about JAAS? And if I were to follow that example and use JBoss and configure it as they did. when I deploy my web application as a war file, and I uploaded the war file lets say on a tomcat server, will it still be secured?

Any help/guidance would be extremely appreciated! Thanks!

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
Abu Assadeq
  • 53
  • 5
  • how jaas should be configured is indeed server dependent and not related in any way to jsf. That is why (at least what I think) has not taken off – Kukeltje Mar 24 '16 at 14:30
  • @Kukeltje Thanks for your reply :) I see, so if I develop my application on lets say jboss then deploy a war it wont be secured on any other server ? that's what i understood from your "server dependent", am I right? thanks again – Abu Assadeq Mar 24 '16 at 14:33
  • 2
    Related: http://stackoverflow.com/q/35994641 – BalusC Mar 24 '16 at 14:34
  • @BalusC thanks I'll make sure to check that out :) – Abu Assadeq Mar 24 '16 at 14:35
  • While I haven't tested it, it should be noted that support for JASPIC (the standard Java EE JAAS authentication counterpart) was finally added to Tomcat 9. By [dynamically](https://tomcat.apache.org/tomcat-9.0-doc/config/jaspic.html#Dynamic_configuration) configuring a provider, one could now (at least in theory) have authentication code that "just works", both on Tomcat and on any Full Profile Java EE implementation, such as JBoss. As for a JAAS authorization Java EE counterpart, while there's a Full Profile SPI for it as well, only few people are inclined to even talk about it... – Uux Mar 25 '16 at 09:34
  • @Kukeltje JAAS is for Java SE. It's not server dependent how to configure JAAS. – Mike Braun Mar 26 '16 at 20:11
  • 1
    @Uux you mean JACC ;) It really isn't that bad and an interesting foundation. It just didn't had anyone pushing it further. It has been maintained but not modernised. Such a shame. It most misses a Factory to register JACC providers. – Mike Braun Mar 26 '16 at 20:24
  • @Mike I certainly value JACC for having bridged the role-`Permission` gap. Unfortunately, there's a discrepancy between JACC's support for custom security constraint *validation*, and an application's ability to (intuitively) *express* complex constraints (e.g. "(caller has roles foo OR bar) OR (caller is UeberPrincipal@abc123) AND (target is SomeEjb@def456) AND (it's currently working hours)") for JACC to evaluate. A lengthy role name could express all that, of course, but many still fail to realize that roles can express more than merely stuff like "manager" and "can-access-acp". – Uux Mar 27 '16 at 15:42
  • (continued) I agree that a factory and standardized group-to-role mapping would be enough for one to actively start using JACC though. I'm qurious as to whether JSR-375 will manage to layer its authorization-related conveniences on top of JACC, rather than completely disregarding it. For the time being I have the impression that--except for Arjan Tijms of course--no EG member has ever mentioned JACC on the JSR's mailing lists. – Uux Mar 27 '16 at 15:42
  • 1
    @Uux Following the EG list I get the impression there's nobody present at all from the original people behind JAAS, JASPIC, JACC and security parts in individual specs in Java EE. Especially the mails from the first month made it look like people "just" wanted something DeltaSpike like (do everything in CDI, ignore existing things). I'm afraid that without a JACC MR to provide a factory, JSR 375 cannot utilise JACC. Because Oracle is in a kind of shutdown mode now I'm also afraid we won't be seeing that MR – Mike Braun Apr 11 '16 at 14:01

1 Answers1

4

JAAS security doesn't exist in Java EE. JAAS is a Java SE framework to secure resources at the class level. You use this for limiting what code that you downloaded (like Applets) can do on your computer.

With Java EE the situation is reversed. You don't download unknown code for a single user (you on your computer), but unknown users log in to your code (that you run on a server).

Some confusion happens because a few servers use the term JAAS for the server specific implementation of what's lately called "identity stores" (the things that store users and roles like ldap).

But:

  • Only an embarrassing small part of JAAS is used (some types like LoginModule)
  • Servers that claim to use JAAS all do it in such different way that you only wonder why they bothered with it to begin with
  • By far not every server uses JAAS. Tomcat, Jetty, Resin, Liberty, and WebSphere don't use it at all.
Mike Braun
  • 3,729
  • 17
  • 15
  • 1
    It's confessedly unfortunate that `javax.security.auth.login` tends to be what's first brought up when authentication in Java EE is discussed. But JAAS is not entirely foreign to Java EE; what usually is, is, as you said, `CodeSource`-based authorization (JAAS added `Principal`-based authorization into the mix as well). The umbrella spec has in fact included a few references on JAAS since at least 1.4, while the Connector spec centers an entire section on it. All in all, JAAS can still be seen as a part of Java EE, albeit not one that application developers can directly count on. – Uux Mar 27 '16 at 15:43
  • Thanks a lot now I understand better :) – Abu Assadeq Mar 30 '16 at 15:58
  • 1
    @Uux The umbrella spec has a chapter on security that uses concepts and terminology that you don't encounter elsewhere. It's almost as if the writer envisioned a JSR 375 years ago,but it never materialised. Connector spec has some interesting sections indeed. Some aspects of JAAS appear in EE, but not in the way people think and a lot of things people call JAAS (like constraints in web.xml) are not JAAS at all. – Mike Braun Apr 11 '16 at 13:27