Integrating J2EE Security with LDAP Walk-thru posted

Discussions

News: Integrating J2EE Security with LDAP Walk-thru posted

  1. This tutorial shows the basic steps involved in using an LDAP server to provide declarative security to an EJB facade layer using Websphere 5.x.

    Read it here

    Threaded Messages (15)

  2. Why...?[ Go to top ]

    To the TSS editors: you do realize that this is not really a programmer tutorial, but is almost only a product-specific tutorial? Why oh why is it posted here and not on the WebSphere product page at IBM!? I hope you were well paid.

    It would be very useful if you post a *real* article about "integrating J2EE security with LDAP" instead of this "how-to-configure-WebSphere" stuff.
  3. Why...?[ Go to top ]

    To the TSS editors: you do realize that this is not really a programmer tutorial, but is almost only a product-specific tutorial? Why oh why is it posted here and not on the WebSphere product page at IBM!?
    I agree
    It would be very useful if you post a *real* article about "integrating J2EE security with LDAP" instead of this "how-to-configure-WebSphere" stuff.
    It's kind of impossible because the container's authentication interface is not standardized yet in the J2EE world. You'll have to wait for JSR 196 to be finalized (http://www.jcp.org/en/jsr/detail?id=196) to have a tutorial product-independant.

    By the way, do someone know why the hell it is so long for this spec to come out. It's been since 2002 that it's in "JSR Review Ballot" stage.

    * Sorry if my english is bad, i'm still learning!

    Alexandre Poitras
  4. Why...?[ Go to top ]

    It's kind of impossible because the container's authentication interface is not standardized yet in the J2EE world.
    It can be implemented as a generic servlet filter for the web context, which should be very helpful for many cases.
  5. I don't mind[ Go to top ]

    Hi Rickard,

    I don't really mind product-specific articles. WebSphere is one of the more user-unfriendly app servers for configuring and I'm sure the TSS readership comes across it from time to time (it has a big market share). It seems to me that if this article helps even a handful of readers, it is worth it because it didn't cost much to post.

    You're a smart guy - why don't you write a generic article on J2EE and LDAP? A lot of the TSS community would benefit. BTW what happened to your relationship with TSS - weren't you the Chief architect at one point in time?

    Regards,

    Gordon
  6. on the other hand[ Go to top ]

    There's always Acegi Security if you're using Spring.
  7. on the other hand[ Go to top ]

    There's always Acegi Security if you're using Spring.

    So this thread wasn't totally useless. I learned about Acegi and CAS. :)
  8. on the other hand[ Go to top ]

    There's always Acegi Security if you're using Spring.
    So this thread wasn't totally useless. I learned about Acegi and CAS. :)

    Indeed, Acegi Security even has an LDAP provider for those who would like a container-independent LDAP solution. It doesn't secure EJBs, though.
  9. on the other hand[ Go to top ]

    It doesn't secure EJBs, though.
    So I would have to avoid EJBs. How sad. :)
  10. Acegi doesn't do J2EE security[ Go to top ]

    There's always Acegi Security if you're using Spring.
    So this thread wasn't totally useless. I learned about Acegi and CAS. :)
    Indeed, Acegi Security even has an LDAP provider for those who would like a container-independent LDAP solution. It doesn't secure EJBs, though.

    This article was about container managed security with J2EE. How could this discussion start promoting Acegi? Otherwise you could have mentioned JGuard as an alternative solution as well. It doesn't look too difficult to create a JAAS login module that makes it work with LDAP.

    Anyway, back to J2EE. Most application servers that I am aware of support LDAP based authentication for their J2EE implementation one way or the other.

    As already mentioned in this thread, there is no standard finalized yet and thus implementation of container managed security is left to the vendors of J2EE container vendor. I am not an advocat of IBM websphere (why should I as an Oracle employee ?), but you can't blame them for a non-existing standard (nor can you blame the author of this article).

    Just my 2 cents on this.

    Frank
  11. Why...?[ Go to top ]

    And what about non-web applications?
    The need for such a tutorial is not clear, IMO. The J2EE security approach is quite simple and straightforward: declare security in the descriptor, delegate implementation to the container.
    So, no tutorial needed for the descriptor part of the problem. And even when the containter-part is not standard, almost all widely used containers use a JAAS approach: some way to configure the realm, some way to authenticate users and retrieve roles, etc.
    So the real question should NOT be why isn't there a tutorial, but why isn't this standarized, and moreover if we WANT it standarized...

    Cheers and happy coding,
    Martin
  12. Why...?[ Go to top ]

    And what about non-web applications?The need for such a tutorial is not clear, IMO. The J2EE security approach is quite simple and straightforward: declare security in the descriptor, delegate implementation to the container.
    J2EE security spec is flawed : http://kgionline.com/annoying/java/annoying_java.jsp#webapp_security_gap

    that means that for complext security developers have to use filter based or other custom solutions.
  13. Why...?[ Go to top ]

    Indeed ironic to see how your "annoying java" blog or whatever it is, is implemented in JSP.

    From the Servlet 2.3 spec:
    The auth-constraint element indicates the user roles that should be permitted access to this resource collection. The role-name used here must either correspond to the role-name of one of the security-role elements defined for this web application, or be the specially reserved role-name "*" that is a compact syntax for indicating all roles in the web application.

    I don't claim that the security approach is the BEST we could think of today. I'm just saying that the fact you don't quite like it doesn't make it crap.
    I can't think of anything easier that letting the servlet container do the work for me. That's why we have containers. That's the J2EE approach.
    Yes, you can do it once (with filters or whatever), make a framework out of it, get it on SourceForge, blah blah. A sick way of reinventing the wheel: you just KNOW the actual wheel is not round, right...? ;)


    Cheers and happy coding,
    Martin
  14. Why...?[ Go to top ]

    Indeed ironic to see how your "annoying java" blog or whatever it is ...
    If you page down on his blog and see his rant on Applets and JWS, you will understand. :)
  15. Why...?[ Go to top ]

    The fact is JSR 196 isn’t here, as I pointed out. Albeit, the next wave of innovation in the J2EE space will be around vendor extensions, now that IBM is a major player. I am not an IBM employee, but at least they have a complete spec for implementing “declarative” J2EE security. It is one thing to talk about J2EE security, but it is another thing to have to implement it on an enterprise-wide scale.

    Anywho, the trick is to not be locked-in by IBM and Tivoli, which is a beast, and be able to provide least-cost SSO using TAI. The article was not intended to be a tutorial, but to “explore” the interfaces that needed to be touched, to provide a complete security design pattern.

    regards, Frank T.
  16. Why...?[ Go to top ]

    To the TSS editors: you do realize that this is not really a programmer tutorial, but is almost only a product-specific tutorial? Why oh why is it posted here and not on the WebSphere product page at IBM!?

    This seems like more of a short-on-news-period-thing than selling out to IBM.