Authentication and Authorization in J2EE


EJB design: Authentication and Authorization in J2EE

  1. Authentication and Authorization in J2EE (2 messages)

    Is it possible that the application do the authentication by third party product (e.g. security server) and do the authorization in the application server?
  2. One of the benefits of J2EE security is that authentication and authorization can be performed transparently to the application.

    Authorization (the process of determining whether a particular request from a particular principal is permitted or not) is generally performed by the container (in both web and ejb-variety). A component can get involved in the decision making process as well, but this typically isn't necessary.

    Whereas, authentication (the process of verifying an identity) is generally not performed by the container itself. Rather, the container will typically be configured to delegate this decision to a platform-wide authentication service such as the Operating System's password system, or LDAP, or something similar. Unless your application has its own private password database, in which case the container will then use that. The approach depends mostly on your particular application/component requirements.

    Whether your particular J2EE server supports security (authorization and authentication services) depends upon your vendor, as does the choices you will have for authentication mechanisms.

    One J2EE server which does support all these capabilities is Borland's AppServer ( Their documentation is available online or in PDF, and describes these various approaches.

    (Professional ethics: I work as a consultant for Borland.)
  3. Just regarding the authorization topic: I would not rely on the container doing authorization, because:
    *) J2EE authorization is rather insufficient. EIther it is declarative, then you have to work with roles. This is nice for a little web-store like the PetStore where you just have admin and customer. But for a "real" application? Only roles. Insufficient. And if you rely on programmtic authorization... well, you have to do everything yourself, the container won't help you.
    *) The second (even bigger?) disadvantage is that if you rely on the container you have the nice "vendor lock in": You cannot switch anymore. Or would you accept it if your OS used unix security yesterday, today it uses NT4 and tomorrow Win2K ActiveDirectory? Maybe in one week it is completely different? So if you want your application deployed on more than one container, don't use J2EE authorization. It is also a tradeoff for the customer, because many appservers use "policy files" for security. Very nice if the customer is used to the WinNT user-management.

    And, BTW, some advertisement: Because we found J2EE security (especially authorization) very insufficient for our products we wrote our own framework being portable across appservers and are now releasing it to the public as COTS component. Take a look at