RSA Cloud load balancing DNS and SSL certs questions

[AndyHardy1]

installed trial, works in one site,

dns and SSL certificate of rsa.company.com purchased from comodo

dns is a single entry on cloudflare and points to 5.5.5.5 (rsa.company.com)

works ok.

we have 2 sites.

we have a load balancer in each site , the F5

planning on installing 3 RSA virtual servers each site, but to keep it simple, we will have 1 on each site.

what SSL certs do i need to purchase for this?

sub domain of say "wip.company.com" and make the F5 authoritive for this yes?

with 2 a records in that of the below for example

idr1.company.com 5.5.5.6

idr2.company.com 5.5.5.7  (these dont need to be external ssl certs?)

then

rsa.company.com IN CNAME rsa.wip.company.com  

what entry do i put in the RSA as my identity router hostname and what external SSL cert do i need to purchase?

[TedBarbour]

Hi Andy - I don't know that I can accurately answer all of your questions via this forum.

By the way, if you are still under your trial agreement you should be able to get help from your RSA Sales Engineer.  If you have purchased the product and maintenance you can open a support case for further assistance.

I would check out Identity Router DNS Requirements for some good info in this area.  As described there, some of the DNS and certificate info depends on whether you are going to support SSO for HFED applications.

Ted

[LenoreTumey]

When I configure the SSO Agent on multiple clusters, I enable High Availability for the cluster, and make sure that both clusters have the SAME load balancer DNS name (for example:  portal.sso.example.com for both).  You might use some fancy DNS configurations (or things like an F5 GTM) to ensure that users get directed to one site/cluster's VIP or another, based on where they're coming from, but the actual portal hostname should be the same for both clusters.  This is because when you configure federation with a SAML application, it'll generally just have a single IdP URL that it will redirect users to (ex:  https://portal.sso.example.com/IdPServlet?idp_id=id1q2w3e4r), so all users, regardless of which cluster they ultimately interact with, will need to connect to the SSO Agent (IDRs) via the same hostname.

I typically configure each IDR to have a hostname within the same subdomain as the portal hostname (for example:  idr1.sso.example.com, idr2.sso.example.com, or idr3-east.sso.example.com).  This way, if I need to download log bundles, I can easily tell which IDR was which by its hostname, and they can all share a wildcard SSL certificate for the protected domain name (*.sso.example.com).