Caution: Articles written for technical not grammatical accuracy, If poor grammar offends you proceed with caution ;-)
I am frequently get asked “Should we deploy the vRealize Automation Identity Appliance or should we connect vRealize to the vCenter SSO server”? The answer to this really depends on what is important to you. There are pro’s and con’s both scenarios. Let’s look at the vRealize Identity appliance first.
vRealize Identity Appliance
The major benefit to running the vRealize Identiy appliance is that it is released as part of the vRealize Automation code stream. This is important because if new features are released in vRealize Automation that have dependencies on specific support from the SSO server the Identity Appliance will be updated with the needed support. This will allow you upgrade when a new version is released without having to worry about external dependencies.
The downside of running the vRealize Identity Appliance is the extra administrative overhead, especially of you are deploying an HA environment. It’s extra servers to support, backup, and maintain on top of the vRA Appliance, IaasS Server, and any deployed for DEM’s/Agents. Not a huge deal, but it’s something to consider.
vCenter SSO Server
The benefit to connecting vRealize Automation to a vCenter SSO server is single point of administration for your SSO infrastructure. It’s not a huge benefit, but it large environments it can make an impact.
There are a number of downsides to using the vCenter SSO server with vRealize Automation. One major downside to me is the two products vRealize automation, and vCenter are on two different release cycles. So it’s possible that a new release of vRealize Automation will come out that requires certain SSO changes and the vCenter SSO server that supports those changes wouldn’t be out for a number of months following.
Another downside would be when performing maintenance to the vCenter servers. If you need to perform maintenance that requires you to bring down the SSO server consumers will not be able to access vRealize Automation during that time as well. Keeping them separate allows you maintain them separately.
It’s a rather difficult decision to make. Personally I would run the vRealize Identity appliance in my test/dev instance and utilize the vCenter SSO in my production deployments. This would allo me to test the latest versions to get familiar with the new features while at the same time keeping my production implementation more streamlined with less servers to maintain, backup, etc.
I believe there are ways to make your SSO infrastructure redundant, which is anyway a good practice, vRA or not
Agreed. I guess it’s a matter of do you want two redundant SSO appliances or one set of redundant SSO appliances to maintain?