Home

News: Book Chapter: Java EE 5 Development with Glassfish: Security

Bookmark and Share Get thread feed

  1. Book Chapter: Java EE 5 Development with Glassfish: Security (6 messages)

    Chapter 8 of "Java EE 5 Development using Glassfish" is on Java EE security, covering how to configure realms for Glassfish and then converting applications to use them properly.
    In this chapter, we will cover how to secure Java EE applications by taking advantage of GlassFish's built-in security features. Java EE security relies on the Java Authentication and Authorization Service (JAAS) API. As we shall see, securing Java EE applications requires very little coding; for the most part, securing an application is achieved by setting up users and security groups in a security realm in the application server, then configuring our applications to rely on a specific security realm for authentication and authorization. Some of the topics we will cover include:
    • The Admin realm
    • The File realm
    • The Certificate realm
    • Creating self-signed security certificates
    • The JDBC realm
    • Custom Realms
    Reply to this

    Threaded Messages (6)

  2. J2EE Security Still Stuck in the Stone Age[ Go to top ]

    It upsets me that 8 years later the integration between J2EE and JAAS is still pathetic. Sun needs to create and implement and standard, including improvements to JAAS, to enable an arbitrary JAAS login session over HTTP. This needs to handle an arbitrary number of steps, each comprised of an arbitrary number of prompts and responses. JAAS itself needs to be updated to better fit the web, or for that matter any client / server technology, to eliminate the dependency on a thread to handle the state of a multi-step login. Until these features exist, J2EE security will only be utilized in books, tutorials, and the occasional open source project started out by reading such things, until it matures to the point of needing more complex login semantics.
    Reply to this Reply to original

  3. Re: J2EE Security Still Stuck in the Stone Age[ Go to top ]

    It upsets me that 8 years later the integration between J2EE and JAAS is still pathetic. Sun needs to create and implement and standard, including improvements to JAAS, to enable an arbitrary JAAS login session over HTTP. This needs to handle an arbitrary number of steps, each comprised of an arbitrary number of prompts and responses. JAAS itself needs to be updated to better fit the web, or for that matter any client / server technology, to eliminate the dependency on a thread to handle the state of a multi-step login.
    Until these features exist, J2EE security will only be utilized in books, tutorials, and the occasional open source project started out by reading such things, until it matures to the point of needing more complex login semantics.
    I agree with everything you said
    Reply to this Reply to original

  4. Re: J2EE Security Still Stuck in the Stone Age[ Go to top ]

    Exactly, it's hard to believe such obvious functionality been ignored for so long. In many projects we start out using JAAS, but quickly becomes useless after a few common application requirements are applied. The opportunity for having a "standard" security approach for JSF was missed. Is there someone from the JSF standards group that can explain this? And, finally, this book's chapter looks like a simple cut-and-paste from a Google simple search. Thanks for the sample, can't imagine how the rest of the books looks like...
    Reply to this Reply to original

  5. Re: J2EE Security Still Stuck in the Stone Age[ Go to top ]

    Thats one of the reasons why we initially started the development of [fleXive]: Fine grained security on a data and UI level. We issue UserTicket's - similar but in my opinion more powerful than JAAS principals - which are used for ACL based authorization. For authentication we currently use the database or as a fallback JAAS - but thats an issue that should be addressed soon. Markus Plesser [fleXive] core developer http://www.flexive.org -- UCS - unique computing solutions gmbh http://www.ucs.at
    Reply to this Reply to original

  6. I see only screenshots and XML[ Go to top ]

    :-(
    Reply to this Reply to original

  7. What I would really like to see[ Go to top ]

    is a full scale production ready security example of some serious website. I don't want to diminish the author's work but who is actually using this type of security in a real world app? Something like an Amazon like security mechanism (switch from HTTPHTTPS without loosing security context or/and session), make only certain features available on a page according to login status etc. Yes, I have tried Acegi but it's one configuration hell and not really suitable for JSF (try built in your own filters along with Acegi or JSF forwards to a page but showing the previous page URL in browser and Acegi simply fails). I'd like to see Sun putting some thought into that and provide some nice security features that suit those needs. Regrads, Joerg
    Reply to this Reply to original