1 2 3 4 5 Previous Next 72 Replies Latest reply on May 14, 2010 11:40 AM by jesper.pedersen Go to original post
      • 15. Re: JcaXAResourceRecovery

         

        "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

           

          "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

             

            "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
              starksm64

              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
                starksm64

                 

                "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.price

                  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
                    starksm64

                    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.price

                       


                      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
                        starksm64

                        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.price

                           


                          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
                            starksm64

                            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.price

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

                              • 27. Re: JcaXAResourceRecovery

                                 

                                "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@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.price

                                    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 ;-)