Top Six Things to Consider with an Identity-as-a-Service (IDaaS) Solution – Blog 5 of 6

5. Robust Access Policies and Multi-factor Authentication (MFA)

 

Today you live with the risks of users accessing many more services outside the corporate network perimeter as well as users carrying many more devices to access these services. Users have too many passwords and the passwords are inherently weak. In fact passwords have become more of an impediment to users than they are protection from hackers and other malevolent individuals and organizations. In short, in many cases, passwords alone cannot be trusted to properly and securely identify users.

Consequently, you need a better solution that incorporates strong authentication and one that delivers a common multi-factor experience across all your apps — SaaS, cloud, mobile, and onpremises. The solution also needs to have access policies that take into account the complete context of the access request and helps to overcome these new security risks. In addition, you need the capability to establish flexible access policies for each app for more granular and adaptive control. For example, if a user is accessing a common app from a trusted device on the corporate network from his home country during business hours ,then simply allow him silent SSO access to the apps. But if that same user is accessing an app outside the corporate network from a device that is not trusted, outside of business hours, and from a foreign country then deny them access — or at least require additional factors of authentication.

Specifically, you need an IDaaS solution that ensures security authentication by combining multi-factor authentication (MFA) and rich, flexible per-app authentication policies.

Multifactor authentication methods should include at least:

• Soft token with one-button authentication to simplify the experience
• One Time Passcode (OTP) over SMS text or email
• Interactive Phone Call to the user’s mobile device and requirement for a confirmation before authentication can proceed
• User configurable security question to act as a second password

Per-app authentication policies should allow, deny or step up authentication based on a rich understanding of the context of the request based on any combination of:

• Time of day, work hours
• Inside/Outside corporate network
• User role or attributes
• Device attributes (type, management status)
• Location of request or location of user’s other devices
• App client attributes
• Custom logic based on specific organizational needs