Updating the SSO Config Store Application using BTDF

Store sign

Updating (by re-deploying) an SSO Application using BTDF does not update the SSO Config Store Application itself. It only updates the custom configuration settings you are storing in that application. One would need to use alternative methods to update the SSO Application itself

 

On a recent project I helped a client investigate an SSO issue. They were getting the following error:

 

“Access denied. The client user must be a member of one of the following accounts to perform this function”

 

 CGM 1 1

 

There was another message in the event log which helpfully pointed out which user account was being denied access (see screenshot below) but the “Application Data” in the error message above does mention which client user and which SSO Application is being used.

 CGM 1 2

 The “Client User” in the screenshot above shows the user account.

 

It turns out that it was a "user error" (configuration issue) in that the “Application Administrators” and “Application Users” groups that specified when the application was deployed were incorrect. To correct this we just needed to specify the correct AD groups. However, resolving the issue turned out to be a little less straight forward than expected.

 

Since we are using the BizTalk Deployment Framework to deploy the application for us we just corrected the SettingsFileGenerator.xml spread sheet where the incorrect values were specified originally and then redeployed the application. However, after the redeployment we were still hitting the same issue.

 

We could see that other custom configuration settings that we updated (or added) where showing up in the SSO application (using the SSOSettingsEditor.exe Tool) but not the new (correct) values for the “Application Administrators” and “Application Users” groups. So, where were those values being held? At first we thought that it might just be caching issue so we tried recycling host instances etc. But the issue wasn’t resolved.

 

We then tried using the SSO Administration UI Tool provided with ESSO but our applications weren’t listed in the tool. I suspect this is because of the type of application being used (I believe this tool is designed to administer “Affiliate Applications” and not “Config Stores” which are the types of applications we are using)

 

Eventually, using one of the command line utilities provided with ESSO, we managed to see the applications stored in the SSO DB. This command lists all the applications:

 CGM 1 3

 

There is another command which then shows the settings of the application itself:

 CGM 1 4

 

Finally, that last command displayed the where the incorrect valued were being held.

 CGM 1 5

 

Hidden behind the yellow “censor” blocks in the above screenshot are the two incorrect AD groups.

We found three options to update these values:

1.   If you can stop the solution, simply un-deploy & redeploy. We couldn't stop and un-deploy because of other applications having dependencies on this application and we weren't in a position to take down the whole solution at that time.

2.   If you can’t do the first option, there is a command line utility that allows one to update an application from an XML file.

CGM 1 6

3.   Or thirdly (not recommended, use with caution) one can update the SSO DB directly from SQL Server Management studio. The “SSOX_ApplicationInfo” table contains rows for all the tables and you will easily spot the fields (columns) which contain the user groups (namely: “ai_user_group_name” and “ai_admin_group_name”).

 

Remember to restart host instances after the changes have been made so that the new settings can take affect.

A possible 4th option would be to add some custom MSBuild task which could update these values and will ensure that these values will always be updated when changed, but I haven’t had a change to investigate that route yet.

 

In summary, re-deploying a SSO Application using BTDF does not update the SSO Config Store Application itself and only updates the custom configuration settings you are storing in that application. One would need to use alternative methods to update the SSO Application itself. If you are in a position where you can stop the running solution, performing un-deploy & re-deploy does however update the settings (in that it completely removes the config store and creates a new config store with the correct settings).

Written by Carlo Garcia-Mier at 00:00

Categories :

0 Comments :

Comment

Comments closed