Adding multi-factor (OTP) authentication to SiteMinder

[Duc Tran]

We are currently on SiteMinder r12.52 SP1 and in progress of doing a parallel upgrade to r12.8 SP2.  We have several large scale web applications that are being protected by the webagent installed on Apache web servers as the web front end.  Our Info Security department is looking into adding an additional layer of security by adding multi-factor authentication (OTP) to our current SiteMinder form-based authentication scheme.

 

We are bringing in Okta to demo their IAM product along with their crucial mult-factor authentication feature, which is included as a standard package and is the primary reason for our management to potentially replace CA SSO with Okta.  Our CA SSO product is deeply integrated into many of our web applications and therefore replacing it with Okta or any other IAM product will be a significant undertaking.

 

To compete with Okta's multi-factor authentication, what is the easiest and most seemless way for us to add One-Time-Password as a form of multi-factor authentication to our SiteMinder infrastructure and implement it to the web application that is currently being protected by the webagent?

 

Thanks in advance for your input.

 

Duc,

[Ashok kumar Muthu]

Hi Duc,

 

The bitter truth is siteminder does not have Multi-Factor Authentication capability by out of the box and you need buy an additional product which is CA Advanced Authentication to support this feature. You can reach out to your account team for demo and licensing options, if you wish.

 

CA Advanced Authentication - CA Technologies 

 

Getting Started - CA Advanced Authentication - 9.0 - CA Technologies Documentation 

 

Being a Services Consultant, I often hear the Customers requirement and their concerns on the SSO with MFA solutions. I hope, Broadcom Product Engineering team is listening to Customers voice and their requirements to create the solutions to meet their needs in this Agile world.

 

Regards

Ashok

[Duc Tran]

Hi Ashok,

 

Thank you for your response and for your honest opinion and answer to this.  Actually, I was a ware that we would need to purchase an additional component to the multi-factor authentication capability with SiteMinder, but what I was hoping to get from the community is to get a sense of how the implementation/integration of the "Advance Authentication" component going be.  Will it be relatively straigh forward without requiring too much changes to our existing SiteMinder setup and infrastructure?

 

In the meanwhile, the Okta folks came onsite earlier this week to work on their demo of their product to our InfoSec department.  I think we will end up purchasing Okta to be used for a small sets of our internal web applications, but overtime it may end up replacing our CA SSO for the rest of our large scale web applications once our SiteMinder support contract expires with CA in 2021.

[Josh Coffman]

One way around this that we have been testing is to implement an MFA solution that is open source or third-party (there are many out there) and then use it to call the JWT authentication scheme and return an SMSession on completion. The JWT authentication scheme effectively allows you to offload authentication to any third-party module you want, and the end result can be an SMSESSION.

[Duc Tran]

Hi Josh,

 

So we are pursuing a third party MFA/OTP product (LexisNexis).  The plan is to continue with SiteMinder for the initial user authentication then user will need to supply the OTP token in order to complete the authentication process.  Can you provide some more info on the JWT authentication scheme that you had previously mentioned?  This sounds like what we are looking for.

 

Thank you!

 

mutas02

HubertDennis

[Zen Leow]

Hi Duc,

 

Here's what I have been doing to have MFA in CA SSO without using CA AA and without packing both 1FA and 2FA into a single custom authentication scheme.

 

First I have the standard form authentication scheme for username and password. this scheme is my "1FA Auth Scheme"

 

Then I create another custom authentication scheme with a higher protection level than my "1FA Auth Scheme". Let's call this "2FA Auth" for the fun of it. This custom authentication scheme can be anything but it will have a login form to redirect to for asking user for the additional credentials like "one time pin" etc.

 

That 2FA Auth form will be a protected realm which is protected by the 1FA Auth Scheme.

 

Those realms that requires MFA will use the 2FA Auth scheme.

 

How it works

1. user attempt to access a 2FA protected resource.
2. No session, so SSO redirects to 2FA Auth scheme form.
3. Still no session, so SSO redirects to 1FA Auth scheme form.
4. User enters username and password.
5. credentials sent to login.fcc and further process by policy server.
6. 1FA successful, SSO redirects back to 2FA Auth scheme form.
7. 2FA Auth scheme form use the SM_USER or SM_USERDN request headers to know who this user is and populate hidden or readonly "username" form field. while the user just need to enter the "password" field with whatever step up option you have adopted. these are then sent to login.fcc then processed by your custom auth scheme.
8. If all successful, user is redirected to the 2FA protected resource with the SSO session that has the higher protection level.

 

By doing this I can have some realms with just 1FA and some realms with 2FA requirements. If the user had access some other app with 1FA requirement, do some stuff then click on something that has 2FA requirement, the 2FA form just pops up without the need to go through 1FA process again since the 1FA session was already created previously.

 

This method allows me to have flexibility over variety of user authentication requirements. I've done chaining of up to 3 auth schemes this way. If done properly, setting authentication requirement in realms is like choosing from a shopping list.

 

point to note. This method requires SecureURL to be enabled (which it always should be anyway)

Reason being when 2FA form is protected and redirected to 1FA form, the URL will have a TARGET in a TARGET and that may have issues in plain text querystring. CA SSO also uses the "-" character for escaping profusely. This also screwed things up for me. Once I implement SecureURL. the whole query strings parameter list is encrypted/encoded. No more issues.

 

Edit: forgot to mention, with this method, you can have potentially very long URL query strings and also a big "REFERER" header. best to increase your max request size limit in your webserver, load balancer and web application firewall of choice. I use 64K. so far so good.

 

Hope this helps someone.

 

regards,

Zen

[Duc Tran]

Zen,

 

Wow.. thank you so much for putting in the time to provide me with this excellent write up!  This seems like a very unique and "tricky" solution!  I had to read through this four times to finally fully understood your logic  

 

I think this is a potential solution, but what I was hoping for is to have the SMSESSION cookie be generated only upon user successfully passed the 1FA form and then redirected to the 2FA form to submit the OTP provided by a third party (LexisNexus) and upon successfully passed the 2FA form, NexusLexus would trigger a call to CA SSO to generate the SMSESSION cookie.

 

What is your thoughts on this?

 

Duc,

[Zen Leow]

Hi Duc,

 

For me, I wouldn't make an outside party to call Siteminder to generate a session. makes debugging and troubleshooting tedious in my opinion.

 

What I would do is create a custom authentication scheme that collects the user credentials and have the custom auth scheme codes call the third party authenticator's API for verification. Depending on the responses returned, then the auth scheme will return either "SmAuthStatus.SMAUTH_REJECT" or "SmAuthStatus.SMAUTH_ACCEPT". That will have the SMSESSION created and given to the browser. And it gives me a lot more control over how things goes.

 

e.g.

The out-of-box RSA auth scheme doesn't cover my client's requirement so I used this method for integrating with RSA Authentication Manager for OTP as a 2FA authentication. 1FA was Integrated Windows Authentication (NTLM).

 

For security reasons, I prefer splitting 1FA and 2FA auth schemes and let realms decide protection level required.

 

If you want to combine 1FA and 2FA together into a single custom auth scheme, that can be done too but you will need to play with how the password field's value will be received by the authentication scheme. you can have first form collect username and password, post to 2nd form which collects the 2FA OTP entry. then package them together to post to your custom auth scheme. the userpassword and the OTP can be put together as a single value separated by a special delimiter, like "\(^_^)/". So your submission can have username as it is, password is <userpassword>\(^_^)/<OTPvalue> then let your custom code do the split and authenticate separately. first verify the password, then verify the OTP. if both ok, return SmAuthStatus.SMAUTH_ACCEPT. if any one of those fails, return SmAuthStatus.SMAUTH_REJECT

 

But also bear in mind the user experience. Is your OTP sent via SMS? Email? or is it a soft/hard time-based token? If it's SMS / EMAIL, then best to split 1FA from 2FA to avoid your users being spammed. if it is soft/hard tokens, then you can explore combined passwords before sending to custom authentication scheme to process. I know some banks do it this way but they are using hard tokens. This is not recommended for SMS and Email OTP.

 

For SMS and Email OTP, you should make sure the username and password is verified first before sending the OTP to the user. That's why I always prefer separation of authentication levels.

 

Good luck

 

regards,

Zen

[chandra rachamreddy]

Is it possible follow this approach if the first form of authentication is Windows authentication scheme ?

[Duc Tran]

Hi Josh,

 

I spent some time looking into the JWT authentication scheme offered by the new r12.8.  I found some good readings from CA Community on this and beginning to get excited about it until I get to the part where it stated that it REQUIRES CA Access Gateway.  I first explored CA Access Gateway with r12.52 and just hated it with a passion.  We have several different externally facing web portals with very high traffic so there are numerous high availability front-end web servers with CA SSO webagents on each of the web servers.  The Access Gateway (SPS) is just a proxy server so that means all of the web traffic needs to go through this single point of entry along with SSL termination.  I really can't see how organizations with highly complex web portals on a very large scale can rely on CA Access Gateway as their reverse proxy server.

 

Maybe the architecture of this product has change and evolved since r12.5?  We have a few dozens of internally facing web applications for employees which I think could benefit from Access Gateway, but for all of our externally facing web portals with very high web traffic, I think Access Gateway would not be suitable for that implementation.

[Josh Coffman]

Duc,

 

I wholeheartedly agree with your hesitation/disdain for the Access Gateway, but...

 

We no longer have the choice of whether or not to use it, because CA\Broadcom has not been adding critical new features to the Web Agent Option Pack. We have an HA enterprise SSO portal that is spread across multiple data centers, and the system can basically never go down. We have avoided using the SPS/AG for more than a decade because of the reputation it has for stability issues and security problems. Now there is just no way to avoid it anymore. We need the OIDC capabilities, because deploying thousands of webagents is simply no longer realistic when apps want to spin up and spin down constantly using containers, and application integration cycles with webagents are just too long. Add to that things like the web-agent vulnerability that was identified last fall, and you quickly realize that having thousands of them in your enterprise is not optimal. So, we (with quite a bit of hesitation) deployed the access gateway in a centralized location to support OIDC and future self-service integration models. We do not use the proxy server features at all at this time, we strictly use the gateway for federation, OIDC, and other newer features like authentication APIs and JWT tokens. Note: One other issue with the access gateway is that because it uses Apache/Tomcat and Java, and it is designed to sit out in the DMZ, it always gets dinged on security scans/audits, which creates a nightmare because to upgrade it, you may have to upgrade the policy servers too. (Which we all know can take a long time). I have seen policy server upgrades take up to 6 months due to finding bugs like memory leaks, policy server crashes, directory search problems, etc. The more product features you leverage, the more likely it is that you will find a bug. I have been running the product at enterprise scale since 2002, and this is just an accepted reality at this point. These bugs have to be identified, analyzed, verified, documented, and fixed by CA, and that back-and-forth process can take months. (I will acknowledge their release quality has been better the last few years, but issues still do occur)

 

Disclaimer: We haven't fully designed the MFA using JWT yet, it is in our backlog, and we will get to it very soon. But this is what I am thinking.

 

First- We will have to have to find a way to keep track of the initial target through all of this, which can be a challenge. We have done it for other processes, so we are pretty confident we can do it here too. Authenticate the user first using UN/PW with a target of the MFA type of your choice, the MFA target should be protected so we can ensure the user has authenticated at the lower level, and to allow for headers to be sent to it, so we can determine things like what types of authenticators the user has registered. At that point, let the third party authenticator applications do their thing, and when complete, create and send a JWT and return an smsession at the higher security level. (We will be looking at both Authenticator applications like MS/Google authenticator as well as some WebAuthN authenticators which can support Security Keys, and built-in bio-metrics like fingerprint scanners, windows hello, etc.)

 

Again, I am not positive that this is possible, because I have not worked with the JWT auth scheme yet, but, it seems like it could be a way to do any type of authentication we want, and then end up with a higher level session token. We also have the API gateway, which really is a swiss-army knife when it comes to making CA SSO do things that it doesn't normally do.

 

If the JWT authentication scheme can in fact be used to do this type of step-up, it basically breathes new life into a product that is seriously lacking in support for modern authenticators. Fingers crossed.

 

One more thing, access gateway aside, CA/Broadcom has really put a ton of effort and investment back into this product over the last few years. The product was dormant for too long, but they are obviously working on some cool stuff now, like JWT support, OIDC support, management APIs, and Container support. GA Release build quality is also orders of magnitude better than it was in the 12.0/12.5 days.

[Sasikumar Chenniyappan]

We have implemented two factor authentication without AA module. 

 

1. Protect target resource http://url/target.jsp 

2. Custom authentication scheme where it picks only username on it's first challenge. 

3. target.jsp realm onAUthChallenge rule triggers on-reject-redirect webagent response to http://url/second.jsp and keep actaul target in SMUSR cookie 

4. Based on user name collected in the first page of authentication, decide user wanted to have one factor or two factor authentication, based on that customise second login screen. 

5. normal flow. 

 

This solution is tested and approved with infosec team. 

[Duc Tran]

Hi Sasi,

 

Thank you so much for sharing.  I think your approach is what we will end up implementing.  The custom auth scheme is the key work here.  We just had a conference call with CA/Broadcom professional services to discuss this requirement and due to the nature of urgency for this upcoming project we have decided to hire CA/Broadcom professional services (which is now known as HCL) to have them do the custom authentication scheme work to integrate with our MFA third party product.

 

Thanks again for sharing, very much appreciate the info.

 

Regards,

 

Duc Tran

[Sasikumar Chenniyappan]

Welcome. Let me know if required more information. For HCL (I knew one expert who joined there recently) this is like CAKE WALK. 

[Padmanabhan Sorimuthu]

HI Sasi,

When you say normal flow on 5th point. Does that mean posting password to fcc file? How is the SMSESSION created?