Forced Re-Authentication: What Is It?

As businesses move toward engaging their customers and employees through more digital experiences, there is an increasing risk to security due to the widening of the attack surface. This is driven by the adoption of emerging technologies across distributed architectures and the proliferation of devices and other digital interfaces.

With the anywhere, anytime access expected by consumers, identity becomes the new enterprise perimeter, maintaining data security and privacy while granting appropriate access based on the user, device, and application. But security concerns don’t end when a user successfully authenticates.

Session hijacking is a growing and dangerous attack vector, potentially leading to malicious actions being performed using a legitimate user’s identity. Despite the many session hijacking mitigation techniques that one may have put in place, there can be instances where a session can still be compromised. This is where dynamic, forced re-authentication can come to your rescue and add another layer of protection to reduce the risk of such scenarios in your applications.

For some time, SiteMinder has offered the ability to designate sensitive resources and force a user to re-authenticate to access those resources, even if the user is logged in and has a valid SMSession cookie. Forced re-authentication provides additional protection for designated resources and has been extended in our 12.8.3 release to work with Layer7 Advanced Authentication as well. This means that you can force a just-in-time risk computation and then dynamically enforce step-up multi-factor authentication (MFA) by Advanced Authentication every time the sensitive resource is accessed. This enhanced re-authentication capability in SiteMinder assumes that the user has initially logged in and that a valid SMSession exists for the user.

This feature will be very useful in scenarios dealing with sensitive resources while not adding additional friction to more mundane requests. The “Transfer Money” section of an online banking website is one example of a sensitive resource. Normally, once a user logs in, they would not have to re-authenticate to transfer money. By defining the money transfer section as a sensitive resource, users must provide their credentials before accessing that section. This sensitive resource protection prevents an unauthorized user from transferring money in case the user stepped away from their system without first logging out or the existing session was compromised in a cross-site scripting attack. By challenging the user to re-confirm their identity, it prevents unauthorized users from taking advantage.

Please refer to DocOps for more information on how to configure this capability.

Forced re-authentication is one of many SiteMinder capabilities to ensure high session security. Read about some more highlights here.

About the author

Madhusudhan Yoganath is currently a member of the product management group at Broadcom, responsible for the strategy and direction of the Identity & Access Management product portfolio. He has close to 17 years of software industry experience, spanning various roles and verticals. He has spent the last 6 years in product management, in the field of Cyber Security and IAM, and was responsible for defining products for the Fortune 1000 customer base. Prior to joining CA technologies, Madhusudhan was a member of the product management team at Security Technology and Response Group at Symantec. He has more than a decade of experience in the field of Cyber Security across Product Management, Pre-Sales and Post-Sales Consulting engagements and focuses on building winning relationships.  Madhusudhan, while originally from Bangalore, is currently based out of Hyderabad’s Broadcom office.