...building hybrid clouds that can support any device from anywhere
There are times when you are required to have a single Security Token Service (STS) (eg. AD FS) pointing to multiple WAP Tenant or Admin Portals. This is a common occurrence when you do not want to have more than one STS instance set up (possibly because it is federated with your enterprise STS and other Identity Providers that you don’t want to keep setting up repeatedly for every environment). Instead, you would like to have multiple WAP installations all pointing to a single STS instance that you can reuse. In this case you have multiple Tenant portals and multiple Admin portals from different WAP installations that need to be registered with AD FS.
When you try to set up the portals as Relying parties (RP) to the STS, the STS is going to complain after the first RP, saying you have a collision with an already existing Relying Party Identifier and will not let you set it up. This is because all your tenant portals have an out-of-the box Realm (aka Identifier) value of http://azureservices/TenantSite. The Realm value is used to uniquely identify a Relying party and the tokens issued for the user will be targeted towards that realm. Hence collisions are unacceptable. In this scenario, you have to change the realm of the portals in your different WAP installations so that they are sufficiently unique from the STS’s perspective.
The following script will modify the realm of the tenant portal. You can run it from any machine that has the Windows Azure Pack PowerShell modules on it.
You will need the following values for this process:
1: $authPortalUrl = 'win-0f2kif9k2tg:30071'
2: $tenantPortalUrl = 'win-0f2kif9k2tg:30081'
4: $dbServer = 'win-0f2kif9k2tg\sqlexpress'
5: $dbPassword = 'pass@word'
7: $newRealm = http://azureservices/mySite
The Realm value should be in a URI format. This is per the specification for the Realm in WS-Fed Protocol. So always ensure that the realm is something of http://value/value.
Provisioning a new Realm to the portal involves 3 steps:
1: $dbValue = Get-MgmtSvcDatabaseSetting -ConnectionString $portalConfigStoreConnectionString -Name 'Authentication.RelyingParty' -Namespace 'TenantSite'
2: $jsonObject = $serializer.DeserializeObject($dbValue.Value)
3: $jsonObject.Realm = $newRealm
4: $newDbValue = $serializer.Serialize($jsonObject)
6: Set-MgmtSvcDatabaseSetting -ConnectionString $portalConfigStoreConnectionString -Name 'Authentication.RelyingParty' -Namespace 'TenantSite' -Value $newDbValue -Force
1: $apiDbValue = Get-MgmtSvcDatabaseSetting -ConnectionString $storeConnectionString -Name 'Authentication.RelyingParty.Primary' -Namespace 'TenantAPI'
2: $jsonObject = $serializer.DeserializeObject($apiDbValue.Value)
4: $newapiDbValue = $serializer.Serialize($jsonObject)
6: Set-MgmtSvcDatabaseSetting -ConnectionString $storeConnectionString -Name 'Authentication.RelyingParty.Primary' -Namespace 'TenantAPI' -Value $newapiDbValue -Force
I have used a JSON serializer in this sample. But if you do not have access to that library, you can use ConvertTo-Json and ConvertFrom-Json PowerShell to the same effect
You should restart the Tenant Portal and Tenant API services for the changes to get picked up. You can verify if the new value has been picked up by visiting the Federation Metadata endpoint of the portal at /federationmetadata/2007-06/federerationmetadata.xml">/federationmetadata/2007-06/federerationmetadata.xml">https://<<portalurl>/federationmetadata/2007-06/federerationmetadata.xml and validating the Realm value.
Once these services are restarted and the new realm value has propagated into the federation metadata, you have to re-establish trust between the portal and the STS. In the sample script provided, I have assumed that the Tenant Authentication Site is the STS. If you are using AD FS, please use the appropriate cmdlets for establishing trust.
1: Set-MgmtSvcRelyingPartySettings -Target Tenant `
2: -MetadataEndpoint https://$authPortalUrl/FederationMetadata/2007-06/FederationMetadata.xml `
3: -ConnectionString $portalConfigStoreConnectionString `
6: Set-MgmtSvcIdentityProviderSettings -Target Membership `
7: -MetadataEndpoint "https://$tenantPortalUrl/FederationMetadata/2007-06/FederationMetadata.xml" `
8: -ConnectionString $portalConfigStoreConnectionString `
Once this is done, Visit the tenant portal and observe it redirect to the Tenant Authentication site. The simplest way to see if the realm was changed properly, is to observe the URL. for eg, my portal redirects to the URI:
Note the highlighted section. This will reflect the new realm that is used by the Tenant site to identify itself. You can also validate the changed realm by looking into the database in the Config.Settings table in the Microsoft.MgmtSvc.PortalConfigStore and Microsoft.MgmtSvc.Store databases.
The Realm value is used to uniquely identify a Relying Party. So in the scenario where you have multiple WAP installations that need to point to the same STS, you should change the Realm values of these portals to unique values. You can modify the Realm value of the Tenant Portal in 3 steps
I have created a Custom Resource Provider in WAP Admin portal. I have created users there. Now, when I login to my WAP Tenant portal, it throws error for SubscriptionId in one of my .js page although the other FileShare and default pages gets it.