I need to deploy seamless SSO for mobile and AD desktops.
This SSO is used to access remote SP (SFDC).
For AD desktops, I selected IWA as my seamless authentication method.
For mobile, x509 client certificate.
There is only one URL that can be used as SSO URL at the SP side, so it means that I need to protected the saml2sso service with multiple authentication methods (based on user-agent header)
What are the ways of supporting both authentication methods for the same SAML2.0 partnership?
I'm have played with redirect.jsp, but it can only be protected with a single Authentication Schema.
I'm planing on using X509 or form authentication schema and some manipulation with proxy rules.
Is there a better way doing this?
You can often roll your own dual authentication scheme using the forms auth-scheme.
The forms authentication scheme is essentially a 302 redirect to any page you want. In your case you can use it to redirect to an asp/jsp page that checks the UserAgent, and then does another 302 to the legit ntlm or cert or forms auth scheme. You need to take a bit of care that the target and other URL parameters are passed through transparently, (the target, and the smagentname in particular) - but that has worked in prior customizations that I have been involved with.
Cheers - Mark
----Mark O'DonohueSnr Principal Support Engineer - Global Customer Success
Adding to Mark's reply, you can also consider using CA Access Gateway to perform suitable redirection based on UserAgent captured:
CA SiteMinder® SPS in an Enterprise - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation
We discussed this approach briefly here :
Seperate authentication scheme based on the client type
Hi Ujwol, that is a good suggestion, but I don't think will quite work out. The main reason is the resource they are protecting is federation one: "protected the saml2sso", those are picked up directly by the federation agent and miss the virtual host settings in SPS where those UserAgent mappings can be applied. But also the user-agent session scheme mapping, doesn't let you change the auth scheme URL you are redirected to (as far as I am aware), it only changes how the smsession cookie is stored (for the alternative session schemes, the smsession cookie is stored in a lookup table in SPS, and the minicookie or sslid or IP address, are used as the unique key to look it up). The SPS then adds the smsession cookie to the request and it continues on.
But you can host a .jsp page on the SPS itself by deploying a .war file,(and setting up a Context entry in server.conf file) if needed, as a way of doing that proxy auth-scheme as I first suggested - so SPS can be useful that way.
Cheers - Mark
Oh yes, missed the federation part
Thanks for all the replies!
The form based authentication is probably the best way managing this process.
The only challenge here is retrieving SAML information (Relay state, SMPROTALURL, SAMLRequest) from the Target variable.
the keys are not url encoded but the values are encoded.
I need to iterate on each key inside the Target and reconstruct the request to the idP.
I'm currently working on a Custom Authentication Schema that can be configured using a simple UI for these cases when multiple authentication is required.
Will update as soon as I have one.