This project has moved and is read-only. For the latest updates, please go here.

SSO Clarification

Topics: Bindings File, Settings Management and SSO
Jun 7, 2010 at 5:07 PM

I was just reading RedDwarf's thread on SSO:  http://biztalkdeployment.codeplex.com/Thread/View.aspx?ThreadId=58470

Please clarify a few things:

1.  If I turn on <IncludeSSO>True in the btdfproj file, then ALL variables (key/value pairs) in the Excel/xml files will be put into SSO.

2. We are trying to put just one important userid/password there, that will not be known to the developers. So either the production team would have to add the values to the Excel/xml file, or we provide them a separate SSO script to store the values in SSO. 

In the PDF doc, you have this sample for MSBuild to store user/pass in SSO. 

<Target Name="CustomSSO" Condition="'$(Configuration)' == 'Server'">
   <UpdateSSOConfigItem ssoitemname="databaseUserName" ssoitemvalue="$(databaseUserName)"/>
   <UpdateSSOConfigItem ssoitemname="databasePassword" ssoitemvalue="$(databasePassword)"/>
</target>

Doesn't this need an SSO AffiliateApplication Name to know where in SSO to store the values? 

Thanks,
Neal Walters

 

Jun 7, 2010 at 5:23 PM

1. Yes

2. Correct:

    <UpdateSSOConfigItem BizTalkAppName="$(BizTalkAppName)" SSOItemName="YourSSOItemName" SSOItemValue="ExplicitValueOrAnMSBuildPropertyReference" />

Thanks,
Tom

Jun 7, 2010 at 7:29 PM

I'd like to contribute a complete working example of an MSBuild to handle the SSO, but first I have to get it working.

I created RunSSOSetup.cmd:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe /p:Configuration=Debug FRB.EC.OSI.BizTalk.Deployment.SSOSetup.proj

 

SSOSetup.proj contains exactly the following:

<?xml version="1.0" encoding="utf-8" ?>
<!--    Special MSBuild to add a userid/password to a BizTalk Application in SSO -->

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="SSOUserPassConfig">

    <PropertyGroup>
        <BizTalkAppName>FRB.EC.OSI</BizTalkAppName>
        <DeploymentFrameworkTargetsPath>$(MSBuildExtensionsPath)\DeploymentFrameworkForBizTalk\5.0\</DeploymentFrameworkTargetsPath>
    </PropertyGroup>
    
    <Import Project="$(DeploymentFrameworkTargetsPath)BizTalkDeploymentFramework.targets" />

    <Target Name="SSOUserPassConfig">
         <UpdateSSOConfigItem BizTalkAppName="$(BizTalkAppName)" SSOItemName="OSIUser" SSOItemValue="testuser1" />
         <UpdateSSOConfigItem BizTalkAppName="$(BizTalkAppName)" SSOItemName="OSIPassword" SSOItemValue="testpass2" />
  </Target>

</Project>


For those that do not know MSBuild:

1) I set the Default Target to: SSOUserPassConfig.  The target could alternatively be passed on the command line as /T:SSOUserPassConfig in the .cmd file.
2) I included the property group to set two variables: 1) BizTalkAppName and 2) DeploymentFrameworkTargetsPath
3) The <Import is required to find the UpdateSSOConfigItem task in the software provided with the BTDF
4) The Target SSOUserPassConfig is basically a subroutine to run the tasks in the target, i.e. to set each desired variable.

It gave these errors:

Build started 6/7/2010 11:07:12 AM.
__________________________________________________
Project "c:\Source\FRB\EC\OSI\BizTalk\FRB.EC.OSI.BizTalk.Deployment\FRB.EC.OSI.B
izTalk.Deployment.SSOSetup.btdfproj" (default targets):

Target SSOUserPassConfig:
    c:\Source\FRB\EC\OSI\BizTalk\FRB.EC.OSI.BizTalk.Deployment\FRB.EC.OSI.BizTal
k.Deployment.SSOSetup.btdfproj(17,6): error MSB4018: The "UpdateSSOConfigItem" t
ask failed unexpectedly.
    c:\Source\FRB\EC\OSI\BizTalk\FRB.EC.OSI.BizTalk.Deployment\FRB.EC.OSI.BizTal
k.Deployment.SSOSetup.btdfproj(17,6): error MSB4018: System.Runtime.InteropServi
ces.COMException (0xC0002A04): The application does not exist.
    c:\Source\FRB\EC\OSI\BizTalk\FRB.EC.OSI.BizTalk.Deployment\FRB.EC.OSI.BizTal
k.Deployment.SSOSetup.btdfproj(17,6): error MSB4018:
    c:\Source\FRB\EC\OSI\BizTalk\FRB.EC.OSI.BizTalk.Deployment\FRB.EC.OSI.BizTal
k.Deployment.SSOSetup.btdfproj(17,6): error MSB4018:    at Microsoft.BizTalk.SSO
Client.Interop.ISSOConfigStore.GetConfigInfo(String applicationName, String iden
tifier, Int32 flags, IPropertyBag properties)
    c:\Source\FRB\EC\OSI\BizTalk\FRB.EC.OSI.BizTalk.Deployment\FRB.EC.OSI.BizTal
k.Deployment.SSOSetup.btdfproj(17,6): error MSB4018:    at SSOSettingsFileManage
r.SSOSettingsFileReader.Read(String affiliateApplication)
    c:\Source\FRB\EC\OSI\BizTalk\FRB.EC.OSI.BizTalk.Deployment\FRB.EC.OSI.BizTal
k.Deployment.SSOSetup.btdfproj(17,6): error MSB4018:    at DeploymentFramework.B
uildTasks.UpdateSSOConfigItem.Execute()
    c:\Source\FRB\EC\OSI\BizTalk\FRB.EC.OSI.BizTalk.Deployment\FRB.EC.OSI.BizTal
k.Deployment.SSOSetup.btdfproj(17,6): error MSB4018:    at Microsoft.Build.Build
Engine.TaskEngine.ExecuteTask(ExecutionMode howToExecuteTask, Hashtable projectI
temsAvailableToTask, BuildPropertyGroup projectPropertiesAvailableToTask, Boolea
n& taskClassWasFound)
Done building target "SSOUserPassConfig" in project "FRB.EC.OSI.BizTalk.Deployme
nt.SSOSetup.btdfproj" -- FAILED.

We know that somehow, Biztalk stores port information in SSO,  But there are no "AffiliateApplications" other than the ones I have manually created.

My BizTalk application name is "FRB.EC.OSI", and it was deployed at the time of my tests.  That is the same name I use in the BTDFPROJ file as my ProjectName and ProductName.

After the above error, I went the SSO Admin Utility, added an affiliate application called "FRB.EC.OSI", ran it again, and got the same error.

 Build started 6/7/2010 11:15:08 AM.
__________________________________________________
Project "c:\Source\FRB\EC\OSI\BizTalk\FRB.EC.OSI.BizTalk.Deployment\FRB.EC.OSI.B
izTalk.Deployment.SSOSetup.btdfproj" (default targets):

Target SSOUserPassConfig:
    c:\Source\FRB\EC\OSI\BizTalk\FRB.EC.OSI.BizTalk.Deployment\FRB.EC.OSI.BizTal
k.Deployment.SSOSetup.btdfproj(17,6): error MSB4018: The "UpdateSSOConfigItem" t
ask failed unexpectedly.
    c:\Source\FRB\EC\OSI\BizTalk\FRB.EC.OSI.BizTalk.Deployment\FRB.EC.OSI.BizTal
k.Deployment.SSOSetup.btdfproj(17,6): error MSB4018: System.Runtime.InteropServi
ces.COMException (0xC0002A05): The mapping does not exist. For Config Store appl
ications, the config info has not been set.
    c:\Source\FRB\EC\OSI\BizTalk\FRB.EC.OSI.BizTalk.Deployment\FRB.EC.OSI.BizTal
k.Deployment.SSOSetup.btdfproj(17,6): error MSB4018:
    c:\Source\FRB\EC\OSI\BizTalk\FRB.EC.OSI.BizTalk.Deployment\FRB.EC.OSI.BizTal
k.Deployment.SSOSetup.btdfproj(17,6): error MSB4018:    at Microsoft.BizTalk.SSO
Client.Interop.ISSOConfigStore.GetConfigInfo(String applicationName, String iden
tifier, Int32 flags, IPropertyBag properties)
    c:\Source\FRB\EC\OSI\BizTalk\FRB.EC.OSI.BizTalk.Deployment\FRB.EC.OSI.BizTal
k.Deployment.SSOSetup.btdfproj(17,6): error MSB4018:    at SSOSettingsFileManage
r.SSOSettingsFileReader.Read(String affiliateApplication)
    c:\Source\FRB\EC\OSI\BizTalk\FRB.EC.OSI.BizTalk.Deployment\FRB.EC.OSI.BizTal
k.Deployment.SSOSetup.btdfproj(17,6): error MSB4018:    at DeploymentFramework.B
uildTasks.UpdateSSOConfigItem.Execute()
    c:\Source\FRB\EC\OSI\BizTalk\FRB.EC.OSI.BizTalk.Deployment\FRB.EC.OSI.BizTal
k.Deployment.SSOSetup.btdfproj(17,6): error MSB4018:    at Microsoft.Build.Build
Engine.TaskEngine.ExecuteTask(ExecutionMode howToExecuteTask, Hashtable projectI
temsAvailableToTask, BuildPropertyGroup projectPropertiesAvailableToTask, Boolea
n& taskClassWasFound)
Done building target "SSOUserPassConfig" in project "FRB.EC.OSI.BizTalk.Deployme
nt.SSOSetup.btdfproj" -- FAILED.

Done building project "FRB.EC.OSI.BizTalk.Deployment.SSOSetup.btdfproj" -- FAILED.

Thanks,
Neal Walters

 

 

 

 

 

Jun 7, 2010 at 7:54 PM

In SSO Admin, you have to select Affiliate Applications and then View/Config Store.  There you would see your SSO app, usually at the bottom since most app names are GUIDs.  If it isn't there, then your other project did not deploy it as you expected (which needs <IncludeSSO>true</IncludeSSO>).  If IncludeSSO is set and you've deployed that project, then you'll have to carefully review its deployment log to look for the SSO deploy output.

Thanks,
Tom

Jun 8, 2010 at 6:40 PM
Edited Jun 8, 2010 at 6:51 PM

Ah, you know what they say about assumptions. I assumed that the only reason for using IncludeSSO was to put all the variables in the spreadsheet into SSO.  As my original question hinted,
I was only interested in putting the special user/pass there. 

So now, I'm facing another issue when I do  a deploy in VisualStudio. 

 "C:\Program Files\Deployment Framework for BizTalk\5.0\Framework\DeployTools\SSOSettingsFileImport.exe" FRB.EC.OSI /settingsFile:"c:\Source\FRB\EC\OSI\BizTalk\FRB.EC.OSI.BizTalk.Deployment\EnvironmentSettings\local_settings.xml" /userGroupName:"BizTalk Application Users" /adminGroupName:"BizTalk Server Administrators"
            Error persisting to SSO:
            System.Runtime.InteropServices.COMException (0xC0002A22): The account name is not valid or does not exist. See the event log (on computer 'SFBZTKDEV01V') for more details.
           

My BTDF had this:

    <PropsFromEnvSettings>ssoAppUserGroup,ssoAppAdminGroup,BAMViewsAndAccounts</PropsFromEnvSettings>

I switched to the new syntax:

    <ItemGroup>
        <PropsFromEnvSettings Include="SsoAppUserGroup;SsoAppAdminGroup;BAMViewsAndAccounts" />
    </ItemGroup>

And now I get this error:

    Target DeploySSO:
        Target DevlSSO:
            "C:\Program Files\Deployment Framework for BizTalk\5.0\Framework\DeployTools\SSOSettingsFileImport.exe" FRB.EC.OSI /settingsFile:"c:\Source\FRB\EC\OSI\BizTalk\FRB.EC.OSI.BizTalk.Deployment\EnvironmentSettings\local_settings.xml" /userGroupName:"" /adminGroupName:""
            SSOSettingsFileImport v1.0.0.0
            Import a settings file (as generated by SettingsFileGenerator.xls/.xml) into the SSO database.
            
            /userGroupName:: Argument expects a paramter

In my spreadsheet, I have ssoAppUserGroup and ssoAppAdminGroup set to a domain\group in the "Default Values" column.

Upon scrolling down further I found this:

C:\Program Files\MSBuild\DeploymentFrameworkForBizTalk\5.0\BizTalkDeploymentFramework.targets : warning : Could not find a property value in the environment settings XML file 'c:\Source\FRB\EC\OSI\BizTalk\FRB.EC.OSI.BizTalk.Deployment\EnvironmentSettings\local_settings.xml' using the XPath '/settings/property[@name='SsoAppUserGroup']'.

Looks like Sso is now cap instead of lower case sso?  I guess we changed it in the spreadsheet and didn't know that corresponding value was imbedded in the .btdfproj file.  So I changed the case in the PropsFromEnvSettings to "sso" instead of "Sso" and now it matches and works.

Thanks,

Neal Walters

P.S.  This is another case where I had to undo four other BizTalk projects in order to redeploy this one.

 

 

 

 

 

 

Jun 8, 2010 at 6:58 PM

Now the MSBuild job (UpdateSSOConfigItem) that I copied above works! 

Should I be able to see the values in one of the SSO tools.  I can now find my app in SSOAdmin.  My user is a member of SSO Admin.

I have also tried Richard Seroter's "SSO Config Store App Mgr" and gets error: "The mapping does not exist.  For Config Store applications, the config info has not been set".

Thanks,
Neal

 

Jun 8, 2010 at 7:24 PM

Clean-up and reploy clarification question:  When I redeploy and/or undeploy, does it remove the Affiliate Application from SSO?

In other words, on local machine, if I do a redeploy, do I have to rerun the special job to put the hidden userid/password back in SSO?

Thanks,

Neal

 

 

Jun 8, 2010 at 8:13 PM

Thanks for the progress updates.  I wish that the XPath syntax wasn't case sensitive on those settings spreadsheet names.  There's probably a tolower() type of thing in XPath that I could use.

I have never used a GUI tool to view and edit the data after it is in SSO.  Going way back, I think this may have been based on a Jon Flanders sample which had a GUI, if memory serves.  It's possible that his old app might be able to open and view the data.  Not sure at all though.

When you redeploy or undeploy it does remove and re-create the SSO affiliate app, so you'd need to call your special job again.

Thanks,
Tom

By the way, we have the same pain from multiple BizTalk apps that build upon each other and have reference links.  I definitely know how much of a pain it is.

Jun 10, 2010 at 1:44 AM

Here were the final points in getting the separate SSO job (code in Mon at 11:29 AM above) to work on the target server.

Changed the Import to:

    <Import Project="BizTalkDeploymentFramework.targets" />

as the BTDF is not installed on the target server.


Had to copy/deploy these files as well due to the imports: 

- BizTalkDeploymentFramework.targets
- BizTalkDeploymentFramework.WiXSetup.targets
- DeploymentFramework.BuildTasks.dll
- Microsoft.Sdc.Common.tasks
- Microsoft.Sdc.Tasks.dll

Neal

 

 

 

 

 

 

Aug 6, 2010 at 11:03 PM
Edited Aug 6, 2010 at 11:10 PM

[Just to summarize above, I wanted the super-secret SSO variables in a separate file outside our SettingsFileGenerator, where the Admin can set the values, and run the above job to set them up]. 

After I ran the custom/manual SSO job discussed above, I always have to go to SSO-Admin, right-click "Affiliate Apps", then "view" then "Config Store", then find my app, right-click Properties, click "Accounts" tab, then add the userid under which my BizTalk host is running.

What's the best way to script this tedious step as well?  Is there another parm on the <updateSSOConfigItem> that allows to specify the user?

I just run this .cmd file now:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe Sample.SSOSetup.proj

Contents of Sample.SSOSetup.proj

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="SSOUserPassConfig">

    <PropertyGroup>
        <BizTalkAppName>FRB.EC.OSI</BizTalkAppName>
        <DeploymentFrameworkTargetsPath>$(MSBuildExtensionsPath)\DeploymentFrameworkForBizTalk\5.0\</DeploymentFrameworkTargetsPath>
    </PropertyGroup>
   
    <Import Project="BizTalkDeploymentFramework.targets" />

        <Target Name="SSOUserPassConfig">
            <UpdateSSOConfigItem BizTalkAppName="$(BizTalkAppName)" SSOItemName="ABCUser" SSOItemValue="xxxxxxxxx" />
            <UpdateSSOConfigItem BizTalkAppName="$(BizTalkAppName)" SSOItemName="ABCPassword" SSOItemValue="xxxxxxxxx" />
            <UpdateSSOConfigItem BizTalkAppName="$(BizTalkAppName)" SSOItemName="ABCBankNumber" SSOItemValue="xxxxxxxx" />
        </Target>

</Project>

 

I think I just solved my own question.  I still have <IncludeSSO> in the btdfproj file, so running the normal install creates the SSO App and configures the user/group.
If I'm correct, I can change the ssoAppUserGroup to be the userid running the BizTalk host instance, correct?  Also for future reference, can I put a comma delimited list of users here, or just one? Currently, I have the ssoAppUserGroup and ssoAppAdminGroup with the same value. 

Thanks,
Neal

 

Aug 7, 2010 at 12:43 AM

A typical install will route the SSO user and admin group names from the settings spreadsheet into the <SsoAppUserGroup> and <SsoAppAdminGroup> MSBuild properties via a <PropsFromEnvSettings> ItemGroup.

You CAN use multiple groups -- separate the group names with a semicolon.  (That's according to the docs for SSO V3...  I've never tried it.)

Thanks,
Tom

Sep 16, 2010 at 11:25 PM
Edited Sep 17, 2010 at 4:42 PM

Here's another follow-up from our real-world experience.  We have found that every undeploy removes the SSO entries. 
This is the usual case that what BTDF deploys, it undeploys. Our Admins don't want to keep the super secret user/pass sitting in that file,
and they don't want to have to dig it up, type it correctly, and re-run after each deploy. 

It might be nice to have a feature to NOT undeploy the SSO settings.  In the meanwhile, I think we'll turn SSO off in our normal BTDF file,
and then in the special SSOSetup discussed above, we will have an option to call the "DeploySSO" target.  Does that make sense?

ALSO - will any of the utilities dump out all the variables and values currently in SSO for an application? 

Thanks,
Neal

RunSOSetup.cmd

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe FRB.EC.OSI.BizTalk.Deployment.SSOSetup.proj


SSOSetup.proj

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="SSOUserPassConfig">


    <PropertyGroup>
        <BizTalkAppName>FRB.EC.OSI</BizTalkAppName>
        <Configuration>Server</Configuration>       
        <IncludeSSO>true</IncludeSSO>
        <DeploymentFrameworkTargetsPath>$(MSBuildExtensionsPath)\DeploymentFrameworkForBizTalk\5.0\</DeploymentFrameworkTargetsPath>
        <DeployTools>.</DeployTools>
        <SsoAppUserGroup>BIZTALKDEV\app_host_userid</SsoAppUserGroup>
        <SsoAppAdminGroup>BIZTALKDEV\dl_aa_bt_sso_administrators</SsoAppAdminGroup>
    </PropertyGroup>
   
    <Import Project="BizTalkDeploymentFramework.targets" />

        <Target Name="SSOUserPassConfig" DependsOnTargets="DeploySSOSpecial">
            <UpdateSSOConfigItem BizTalkAppName="$(BizTalkAppName)" SSOItemName="ABCUser" SSOItemValue="xxxxxxxxx" />
            <UpdateSSOConfigItem BizTalkAppName="$(BizTalkAppName)" SSOItemName="ABCPassword" SSOItemValue="xxxxxxxxx" />
            <UpdateSSOConfigItem BizTalkAppName="$(BizTalkAppName)" SSOItemName="ABCBankNumber" SSOItemValue="xxxxxxxx" />
        </Target>

        <Target Name="DeploySSOSpecial">
            <Exec
              Command="&quot;$(DeployTools)\SSOSettingsFileImport.exe&quot; $(BizTalkAppName) /settingsFile SSO_Load_settings.xml /userGroupName:&quot;$(SsoAppUserGroup)&quot; /adminGroupName:&quot;$(SsoAppAdminGroup)&quot;"
              Condition="'$(Configuration)' == 'Server'"/>
        </Target>
       

</Project>

We only plan to get the three variables above, none of the others in the xml/spreadsheet are used at runtime. 

SSO_Load_settings.xml - just a dummy file because I think we have to pass it. 

<?xml version="1.0" encoding="utf-8"?>
<settings>
  <property name="temp">temp-value</property>
</settings>

 

 

 

Sep 17, 2010 at 4:52 PM

That seems like a reasonable approach.  There is a tool that is included in the source code called SSONameValueDump under Tools\SSOSettingsFileImport.  You can also view and edit the deployed settings using the SSOSettingsEditor GUI.  The downside to setting IncludeSSO to false is that you will no longer have a Start menu shortcut for the SSO Settings Editor -- but the EXE will still be installed.  If you'd like, please go ahead and enter a feature request in the Issue Tracker for the skip SSO undeploy option.

Thanks,
Tom