1 2 3 4 5 Previous Next 72 Replies Latest reply: May 14, 2010 11:40 AM by Jesper Pedersen Go to original post RSS
  • 15. Re: JcaXAResourceRecovery
    Adrian Brock Master

     

    "bill.burke@jboss.com" wrote:
    What really sucks is that JBM is going to have to figure it out for every single app server out there if it wants to be usable in different environments.


    Not really, the JCA layer should be doing this, providing you integrate JBM via JCA.

    We're discussing how to make this as seamlessly as possible within JBossAS.

  • 16. Re: JcaXAResourceRecovery
    Bill Burke Master

     

    "adrian@jboss.org" wrote:
    "bill.burke@jboss.com" wrote:
    What really sucks is that JBM is going to have to figure it out for every single app server out there if it wants to be usable in different environments.


    Not really, the JCA layer should be doing this, providing you integrate JBM via JCA.

    We're discussing how to make this as seamlessly as possible within JBossAS.


    It is quite possible you're going to have the same exact Subject configuration problems in other application servers. Which was back to my original point of that the JCA specification is incomplete, that we need to solve recovery problems within JCA spec as well.

  • 17. Re: JcaXAResourceRecovery
    Adrian Brock Master

     

    "bill.burke@jboss.com" wrote:

    It is quite possible you're going to have the same exact Subject configuration problems in other application servers.


    Configuring security credentials has never bean in any JavaEE spec
    with the possible exception of the recommendation in the JCA spec
    that an MCF includes standard "User" and "Password" properties.

    I'd imagine other appservers have their own methods for fixing this 1% usecase?
    If they don't then its another reason to use JBoss (if only a small market share :-)

  • 18. Re: JcaXAResourceRecovery
    Scott Stark Master

    How authentication fits into javaee was the subject of jsr196 (Java Authentication SPI
    for Containers). It was not integrated into javaee 5 though. Your never going to have a standard properties file, or xml file for this info. There is an extension to the JAAS Configuration object that will have provider specific stores. All of our containers need to move to supporting this type of security aspect.

    The getX(username, password) of api is broken as it exposes security as an api with a non-extensible representation of identity and proof of identity rather than an aspect that can be configured for the operation environment.

  • 19. Re: JcaXAResourceRecovery
    Scott Stark Master

     

    "weston.price@jboss.com" wrote:

    How about a JDBC deployment that only support application-managed security? What if this is required information and can only be done via
    getConnection(username,password)?

    Then the configuration referenced by jca should map to a fixed username and password based security aspect that populates the caller Subject with the PasswordCredential.

  • 20. Re: JcaXAResourceRecovery
    Weston M. Price Master

    Thus defeating the purpose of application-managed security to begin with. Now you have a recorded credential (username/password) somewhere. Oh, BTW, you are assuming that the account has the appropriate DB permissions to execute recovery right ;-)

  • 21. Re: JcaXAResourceRecovery
    Scott Stark Master

    No, application managed security means an application context specific security aspect. If you want it hard coded in a class file the aspect uses a classloader. Same for a properties file. The point is, there is no reason why application managed security means that the username and password have to be passed to the jca provided connection factory getConnection call. If it is available because some user passed it in, fine, but it is not how server frameworks should be coded.

  • 22. Re: JcaXAResourceRecovery
    Weston M. Price Master

     


    The point is, there is no reason why application managed security means that the username and password have to be passed to the jca provided connection factory getConnection call.


    Yes it does. Unless you want to put the ConnectionRequestInfo data somewhere else, like a properties file there is no way for the JCA layer to be able to reconstruct a connection for recovery in this scenario. If it's being yanked from somewhere else, fine, but at that point your are no longer in application-managed security land your in a half ass *-ds.xml file land with the security information residing in a different place.


    If it is available because some user passed it in, fine, but it is not how server frameworks should be coded.


    Propose an alternative to the problem:

    A connection that has been created via getConnection(username, password) has failed. The RecoveryManager needs to be able to recreate the connection and initiate recovery on the underlying resource. So, what should the JCA layer do. Remember, you don't have the username/password because it is 'application managed'. Where does this information come from?



  • 23. Re: JcaXAResourceRecovery
    Scott Stark Master

    Since is a potential security issue to store this in the recovery state, you have to be able to override it. If it means the admin initiating the recovery has to supply it, so be it. You can't assume that because application managed security originally created the connection, that this has to be used for recovery. The application may have secure ways of obtaining this info. That same mechanism or equivalently strong approach would have to be setup for recovery.

  • 24. Re: JcaXAResourceRecovery
    Weston M. Price Master

     


    Since is a potential security issue to store this in the recovery state, you have to be able to override it. If it means the admin initiating the recovery has to supply it, so be it.


    BINGO! This is all I have been saying since being flamed this morning. I have to have that information somehow, someway. Scenarios requiring Subjects and CRI are not all that uncommon. They most certainly do not constitute 1% or less of my use cases as was previously suggested.

  • 25. Re: JcaXAResourceRecovery
    Scott Stark Master

    This still is not application managed security ala getConnection(username, password). The admin may have to use a hardware key fob to supply this info. If the recovery security configuration allows for a ConsoleCallbackHandler to obtain the information, that is the user's choice. Its still external configuration to jca as far as I can see.

  • 26. Re: JcaXAResourceRecovery
    Weston M. Price Master

    Can someone shoot me? Please? Adrian I will buy you a pack of cigarettes if you kill me know...

  • 27. Re: JcaXAResourceRecovery
    Adrian Brock Master

     

    "weston.price@jboss.com" wrote:

    Yes it does. Unless you want to put the ConnectionRequestInfo data somewhere else


    The CRI is optional.

    For recovery the MCF must support
    createManagedConnection(subject, null);
    see JCA 1.5 spec 6.5.3.5

    So all we need is a way to construct the subject, e.g. user/password
    or the name/location of a certificate (it really depends upon
    what "authentication-mechanism" we and the rar support).

    As Scott says, it could even involve logging a warning and asking the admin
    to go to the jmx or admin console and entering it on every reboot.
    But probably not, that's not very zero configuration. :-)

  • 28. Re: JcaXAResourceRecovery
    Adrian Brock Master

     

    "adrian@jboss.org" wrote:
    it really depends upon
    what "authentication-mechanism" we and the rar support).


    When I say "we" I mean what jboss-security supports or users write as login modules. :-)

  • 29. Re: JcaXAResourceRecovery
    Weston M. Price Master

    Again, your just putting the data somewhere else. CRI was a bad choice of words...and thanks I have read the spec...

    Let me know how it turns out ;-)