Symantec Access Management

Anyone know if it's remotely possible to piece together a "cert and form" custom authentication scheme?

Looking at the SDK overview, they have an SM_CRED_CERT_OR_FORM but I don't see one for the "CERT AND FORM".

The scenario I have is attempting to implement a "username hint" functionality like Windows has for logging into multiple identities with one certificate. SiteMinder currently fails this because it matches more than one user during cert mapping if that is assigned to more than one user.

I also don't want the user to have to enter a username+password, but instead just perform certificate authentication + passing the user they wish to log in as in the form. The mapping would execute the LDAP search based on both those pieces of information and match only a single user.

To answer the question SSO does include out-of-box auth scheme - is this what you are looking for ?

X.509 Client Certificate and HTML Forms Authentication Schemes - CA Single Sign-On - 12.52 SP1 - CA Technologies Documen…

The problem with OOTB setup is mapping certificate to multiple identities.

In this case I have one smartcard, but that cert can map to 5+ users. SiteMinder does not seem to have a way to handle this OOTB, it fails every time.

If I remove the multiple mapping, so it goes only maps to one user, then it works with provided capabilities.

-----------

Also we use the ACA add-on from global delivery to do complex mapping to ensure uniqueness across dozens of issuers.

IF I assign the ACA module to the "cert and form" auth scheme it crashes the Policy Server every time a log in is attempted. So that's not feasible at all in current state.

-----------

So I need some way to get in between this all and add some additional logic to things; i.e., do the proper certificate mapping and identify correct user when both a form+cert are presented (instead of failing cause cert matched multiple)

So just thinking out loud here...but the OOTB "cert and form" adds parameter like ../login.fcc?cert+form

If I add that parameter to a custom redirect (e.g., ../mycustomlogin.fcc?cert+form) and then set it up just like the standard scheme, would the FCC pick up the "cert+form" parameter and passthrough both cert and form to my custom auth scheme???

Really just need some way to get both certificate + submitted username into our custom scheme at the same time.

Hi Claudio,

You may look at the GD Module

SmX509CertAuth Solution Module

   "With the MutlipleMatch optional parameter, you

    can configure the auth scheme to successfully

    map a certificate even when it matches multiple user accounts"

    https://support.ca.com/phpdocs/7/5262/SmX509CertAuthuthInstallConfigV2_10.pdf

Out of the box from the Policy Server, there are 2 type of Cert / form Authentication

Scheme, but for both, you cannot provide only the username. You should provide also the

password.

X509 Cert or Form

https://docops.ca.com/ca-single-sign-on-12-52-sp1/en/configuring/policy-server-configuration/authentication-schemes/x-509-client-certificate-or-html-forms-authentication-schemes

X509 Cert and Form

https://docops.ca.com/ca-single-sign-on-12-52-sp1/en/configuring/policy-server-configuration/authentication-schemes/x-509-client-certificate-and-html-forms-authentication-schemes

Best Regards,

Patrick

No Claudio but ...we do have ACA module here already.

Been trying that option with no luck thus far. Just always get this in the Policy Server log file. Not sure what I missed.

SmX509CertAuth: No StepUpCertToken was provided to StepUp Cert Auth Scheme!
.
.
.

[** Status: Authentication Attempt Failed. ]

==========

FINAL EDIT....ACA using cert+form stepup is a no go. As usual it's completely unstable and crashes the Policy Server.

This module from global delivery has been so very bad for stability.

At this point, even after all my efforts to try and make it work...once invoking the step-up and going into the authenticateuser, Policy Server dumps and restarts. Nice!!!!

Looks like we really need to go a custom auth scheme route and try to make our own stable schemes : /.

Your use-case sounds more like impersonation.

1) Authenticate using certificate

2) "Impersonate" another user identity

So instead of solving it at authentication, you might want to look into the impersonation capabilities of CA SSO?

best

Pascal

Hmm perhaps. I will take a look through those to see if that will cover these scenarios.

So going through impersonation, not sure that meets our requirements either. Documentation is pretty sparse in details, but even if it worked what I'm stuck in is:

How do I ensure X user is authorized to impersonate only Y user? But A user is authorized to impersonate only C user?

Additionally, if I read the configuration steps properly, every application that wants to use impersonation has to setup the "ImpersonateStart / User" rule. That's a pretty big headache when really we actually want something pretty simple.

You can achieve "Impersonator" and "Impersonatee" authorization using groups / policies in SiteMinder. Have you had a look at http://www.ca.com/~/media/Files/Add-OnServicesComponents/Impersonation-for-CA-SiteMinder.pdf ?

In my view it is also a huge benefit that the application sees that an actual other identity was taken over. Of course it needs quite a lot of administration in some way, but how would you solve that with the authscheme / cred collector extension?

I looked at the roles but as I read it, my understand was essentially something like: Group A Impersonators could take on Group B Impersonatee

So basically anyone that is an Impersonator could take on the identity of any of the Impersonatee group.

In that situation, how could I get more detailed without complex rules? I.e., User #1 is allowed to impersonate Users A and B but NOT Users  C and D. User #2 is allowed to impersonate Users C and D but NOT Users A and B.

Was thinking along the lines of having an attribute on the accounts like "authorizedUsers" and would need to do a policy such that ("ImpersonatorID" IN authorizedUsers).

In the case of the custom authentication scheme that would be handled by certificate mapping using our unique cert map + the ID sent in the POST. Such that it would do like (&(testAccount=[id entered by user])(authorizedCertUser=[upn from certificate])). IF the user was authorized to use that account then their UPN (or whatever else we want to use for the cert) would be added to the account and thus find a single match to the testAccount user and authorized based on matching the authorizedCertUser to what was presented during authentication. IF the user was not authorized, then the mapping would fail to find a user and thus authentication failed so no session established.

I do like the security considerations of impersonation though -- knowing WHO is taking on that identity role (impersonation) and we could only explicitly allow it for certain apps as an added control. Just seemed like managing it would be difficult. But if I can get it to work with the above rule concept then might work out just fine.

Quick update. It appears we'll end up going with the ACA module option for Cert and Form stepup with multi-match option.

I marked the reply mentioning this as the correct answer.

One thing for anyone wanting to implement it, there's a couple known issues (opened cases and should be addressed in future release):

1 - If you have an incorrect path the configuration file in the auth scheme, it will crash the Policy Server. Make sure you enter the right path.

2 - To do the multiple match step-up you also need to include this in the parameter list "multiplematchresolution=StepUp" . This was not in the document included with the module.

If you don't do that in the scheme then the errors will say that the authenticated user did not match one of the DNs of matching certificate.

E.g.,

fcc=https://mylogin.company.com/certandform/SmX509StepUpLogin.fcc?cert+forms;option=StepUp;tokenTtl=120;tokensep=~;MultipleMatch=yes;multiplematchresolution=StepUp;cfg=C:\PSPath\SmX509CertAuthSettings.cfg

--------------------------

And an helpful hint that at least seems to work ok so far

If you want all your users to be in the same OU in a directory, leverage the "User Object" on the user directories. Since it just uses the Certificate Mappings defined, if you also need to support normal cert-only authentication but assign that cert to multiple users it will fail.

To support both the cert+form w/ mapping to multiple users and cert-only w/ mapping to a single user, specify a unique attribute to identify each group. This way when the search is executed for cert-only it finds ONLY a single user for normal log in. But during cert+form of a "privileged" (or shared or test or whatever others you have) account it will fall to DirB, find multiple users, and step-up to higher level in this case based on the multi-match option in the scheme.

Example:

DirA

Description: Standard accounts with single matched certificate

User Object: (!(accountType=privileged))

DirB

Description: Privileged accounts

User Object: (accountType=privileged)