11 Replies Latest reply on Aug 7, 2012 2:10 PM by B Bouchard

    Integrating BMA with a Source Code Repository

      Share:|

      We recently installed BladeLogic for Middleware Automation and have begun integrating the product with our Clearcase source code repository, but have run into a small snag, I was hoping someone could help answer.

       

      Our Middleware environment consists of WebSphere servers which we log into using our Active Directory login information.  When we create a server profile, it appears we need to save this information as part of the profile, but the connection information will be different for each person using the tool.  I was thinking we could save the profile without checking off the "Use Secure Connection" box and then check that off and fill in the UserName/Password each time, but it seems like it would be pretty easy to end up saving my id/password into clearcase and open the doors to someone else coming in with my credentials later on.  From the security team's standpoint here, they're not thrillled with that solution.  We could use a shared id/password, but we got away from doing that so we could better tell who was making changes and when.

       

      So, I'm curious... How do groups typically handle this scenario?

        • 1. Re: Integrating BMA with a Source Code Repository

          Typical way is to save server profiles in the source code repository using its ACLs management capability for only the corresponding user could access it.

          1 of 1 people found this helpful
          • 2. Re: Integrating BMA with a Source Code Repository

            Groups typically use a service account on the WebSphere system that is dedicated to BMA, but most of them also automate BMA executions and only use the UI to develop the xml packages.  That is the easiest solution but may not satisfy your security requirements.  Another solution is to do a little scripting with the BMA CLI and it's createServerProfile mode.  You could pass the username and password to the script and it could overwrite the username and password within an existing server profile.  That same script could then run the CLI using that server profile for a preview, snapshot ...etc.

            1 of 1 people found this helpful
            • 3. Re: Integrating BMA with a Source Code Repository

              Hi Cass 

               

              Using a single service account is not an option for us. We do plan to use the CLI for a lot of the work, but I don't forsee us getting away from the UI  completely, which means we'll have to figure out a solution for this particular issue.

               

              I've spoken with our Clearcase administrator about the ACL options within that tool, and he has indicated he's done something like this before, so we'll try to set something up along the lines of what Fred suggested and see how that works for us.

               

              Thank you both for your quick responses!

              - Brian

              • 4. Re: Integrating BMA with a Source Code Repository

                The ACL's in clearcase will only control access to the file based on clearcase users.  It will not change the username/password stored inside the server profile.  This means it will not change how BMA connects to WebSphere.  A source code repo that changes the source code based on the user logging in makes me nervous. 

                 

                Environment consistency is the goal of BMA.  The best way towards that is development in the eclipse UI and automation through the CLI.  In my opinion the central tenet of the tool is "Configuration is Code".  Create the "code" version it and promote it along with your applicaiton.

                • 5. Re: Integrating BMA with a Source Code Repository

                  But each user could use his own profile that contains his own credentials...

                  • 6. Re: Integrating BMA with a Source Code Repository

                    Absolutely, although you would need to keep tokensets and and filters in sync between all of the user specific server profiles for a cell, negating the beneifts of managing them in clearcase in the first place.

                    • 7. Re: Integrating BMA with a Source Code Repository

                      Cass Bishop wrote:

                       

                      Absolutely, although you would need to keep tokensets and and filters in sync between all of the user specific server profiles for a cell, negating the beneifts of managing them in clearcase in the first place.

                       

                      This is what I was afraid of.  Just to be clear, I think we're on the same page as far as using the CLI for applying changes, and I understand we can manipulate the userid/password when running from the CLI.  The issue I'm concerned about is totally within the UI.

                       

                      Simplified use case,

                       

                      We have 2 users who both want to use the UI to create configuration packages and manage tokensets.  But the profile they are working with is saved in surce control with a user/id password attached to it.  We can't use a service account to access the environment, so in order for any work to get done in the UI, it sounds like (on the surface) we have to update the id/password each time we check the file out to make changes (assuming we actually want to connect to the administration console from the UI), or we'll be connecting with someone else's credentials.

                       

                      I feel like I must be missing something very basic here. Frankly, I was surprised the UI forces you to save an id/password at all.   It would be ideal (in my opinion) if you could save the profile with the check box "Use Secure Connection" checked, but not save the id/password.  Then, if you tried to connect, the UI would prompt you (or throw an error) indicating you need to add your credentials.  It feels like the server profile itself should be separate from the connection information to get into the console. Administrator access to a cell is a many to one relationship, but the UI seems to force a 1 to 1 relationship between a profile and user access.

                       

                      It feels like the best we can do at this point is put bogus information in the server profile and then change it each time we want to use that profile from within the UI.  But again, what happens if personA make some changes and updates their id/password in the process.  Then personB comes along and makes additional changes, but does NOT update the id/password.  When they connect, they will connect using personA's credentials, which is unacceptable.  Unless there is some way to override that id & password from the UI, I'm sensing there is a good solution to this. - unless you do as Fred suggested, which is to have separate profiles for each person/cell...  but then it seems my next post will be, "What's the best way to keep all these tokensets in sync between multiple profiles." 

                      • 8. Re: Integrating BMA with a Source Code Repository

                        You can have a "global" profile where you update the tokensets and filters and each user is free to synch with it or to keep his specific ones (new token set editor makes this easy even if manual). However, I agree that's not the best. But what this clearly shows is that token set shouldn't be part of profile but should be a separated file.

                        Could be also very good to have user/password files out of profiles.

                        • 9. Re: Integrating BMA with a Source Code Repository

                          I agree, Fred.

                           

                          I can understand the tokenset being associated with a profile, because it sort of makes sense that you would have 1 master tokenset per cell (in WebSphere) and the idea is consistency throughout.

                           

                          But you can clearly have multiple id's with the same administrator access to the same cell, so tying the two of those together really seems to tie our hands.

                           

                          It sounds like, given our scenario, my best course of action at this point is to open a support case and see if there is a way to work around this and/or create an enhancement request for the product.

                          • 10. Re: Integrating BMA with a Source Code Repository

                            I have this discussion with most customers.  My question is always, "How are you going to automate if you cannot use service accounts to connect to WebSphere?"  Using a service account through automation just moves the audit trail from WebSphere to your automation framework.  In the case of BSA your audit trail is the user who executed the job.

                            • 11. Re: Integrating BMA with a Source Code Repository

                              Cass Bishop wrote:

                               

                              I have this discussion with most customers.  My question is always, "How are you going to automate if you cannot use service accounts to connect to WebSphere?"

                               

                              As far as I can tell you can't, but that's not because it isn't possible. It's because the tool is a limiting factor. 

                               

                              We have 4 middleware administrators that can all manipulate WebSphere configurations manually using their own connection information and there is a reporting structure in place that shows who logged in and what changes they made.  Why does an automation tool have to force us away from an existing security infrastructure.

                               

                              On the surface, there is an easy fix (though I completely understand under the covers it may be MUCH more complicated than it seems).  Store the userid/password separately from the ServerProfile.  The information about what you are connecting too should be totally separate from the information about who is connecting.  If that were the case, the answer to your question would be ...  everyone uses a shared Server Profile, but passes their own credentials for authentication/authorization purposes.

                               

                              Keep in mind, I'm not arguing that BMA allows us to do it, I just don't see why it can't with some "slight" modifications.