Navigating the access management space can bring forth a host of new challenges, one of which may be the migration to a new access management solution. This blog is aimed at those of you who are in the process of considering an exit from your current access management provider and evaluating the effort required to do so.

Let’s kickstart this discussion by showing you just how easy it is to migrate from Okta to OneLogin access management solutions. We are going to break up this topic into two parts, with part one focusing on your valuable end users.

When it comes to planning your migration from Okta to OneLogin, one of your top priorities will likely be minimizing disruption to your end users. Moreover, you will be concerned about ensuring that your existing identity security posture is at the very least maintained during the migration, and ultimately, increased once all services have been migrated over to your new OneLogin solution.

With these priorities in mind, we recommend you approach your migration project with the following five core principles as your guiderails for success.

1. Users should be able to use the same authentication factors they are using today, where possible, with the new OneLogin solution. (This includes passwords where password-based authentication is still in place.)
2. Users should be able to access the same set of applications and resources that they can access today when the new OneLogin solution is in place.
3. MFA re-registration, where required, should be strictly controlled. For example, users should be forced to perform Okta MFA before being allowed to register MFA factors with OneLogin.
4. User profiles in the Okta solution should be replicated in the new OneLogin environment (standard and custom attributes).
5. Users are given the same level of access within the integrated applications (i.e. licenses, groups, privileges, roles, etc.).

In this blog, we will cover the first four items. We will address the process of migrating applications in our next blog.

To deliver a successful migration project, we will need to identify the best approach to take when it comes to getting users into OneLogin and configuring the relevant authentication factors in a way that is as seamless and secure as possible. The approach taken will be based on how your current Okta environment is architected and whether you want to keep this kind of architecture with your OneLogin solution or use the opportunity to transform your environment to your desired end state.

Before we dive into these details, there are several general steps you should start with, regardless of how your current Okta environment is architected and what your desired OneLogin end state is. These include the following items:

• Set up branding in your new OneLogin environment to mirror the current branding elements from your Okta solution.
• Perform an attribute mapping exercise to identify the number of custom fields that will need to be created in your new OneLogin environment to be able to mirror your existing core user profiles.
• Create the required custom fields in OneLogin following the completion of your core user attribute mapping exercise above.
• Create the required number of roles in your OneLogin environment to correspond to your existing Okta groups. This can be done via the admin console or for large numbers of roles/groups, you can use the OneLogin Admin API or IaC tools, such as Terraform.
• Create OneLogin mappings to automatically assign roles to your users (when they are eventually created) to mirror the same logic currently in place with Okta group rules.
• Create a Trusted IdP connection between the OneLogin and Okta environments (using OIDC) and use this TIdP as an authentication factor in your OneLogin environment via our Trusted IdP as a factor capability. This factor can be used to redirect users to perform their existing MFA at Okta the first time they sign into OneLogin, ensuring that users must perform Okta MFA before being allowed to enroll in OneLogin MFA.
• Create a user security policy in OneLogin which will require the Okta MFA (via TIdP as a factor) and apply this to users the first time they sign in to OneLogin using our pre-authentication Smart Hook capability.
• Enable the required other authentication factors you will use in your OneLogin solution and create user security policies, as required, to meet the general day-to-day needs of different groups of users in your solution. Create another series of OneLogin mappings to automatically allocate these security policies (via OneLogin groups) when your users are created.

User Migration

With the above items in place, you are now ready to start loading your users into your new OneLogin solution. In the next section, we will present several different approaches you can take to achieve this task. The recommended approaches will be specific to the desired end state you have for your IDaaS solution.

Traditional Hybrid Identity as a Service (IDaaS) Architecture

In this case, your desired end state is to maintain a traditional approach to your new IDaaS solution whereby users will be synchronized into your new OneLogin environment from an existing on-prem directory such as AD or an LDAP directory. Users will also be required to perform password-based authentication against the on-premises directory. You may have an HR-driven identity solution in place which is supported by integrations between your HR directory and your AD/LDAP via an existing on-premises IGA tool.

In this scenario, there is a very simple path to get your users into your new OneLogin environment and ensure they can use the same set of credentials for password-based authentication.

1. Install Active Directory/LDAP Connectors in your environment and configure them to communicate to the same user stores that are currently supporting your Okta implementation.
2. Configure the required attribute mappings on your Active Directory/LDAP Connectors to ensure the required attributes are synced to the OneLogin Cloud directory to enable the core user profile to match what is currently in place in your Okta environment.
3. Sync several test users and validate that the user profile in OneLogin matches the profile in Okta and that the required OneLogin roles and groups have been automatically allocated to the user.
4. Inform your test users to log into the new OneLogin environment and validate that authentication against your AD/LDC is working as expected. The test users will be forced to complete Okta MFA before they can establish a session to OneLogin where they can now enroll securely to OneLogin MFA.
5. Sync the rest of your user base as required from your AD/LDAP into OneLogin and review your environment to ensure the number of users matches the expected outcome.
6. Plan your communications to instruct your users how to sign in to the new OneLogin App Portal with their existing Okta credentials and how to configure the required MFA factors on their OneLogin account.

So, six steps and you’ve got all your users in. That’s not so bad, right?

Cloud-Only IDaaS Architecture

In this case, your desired end state is to move to a solution with the OneLogin cloud directory being your IT directory source of truth and you want to use only cloud-based authentication factors in your solution. You may already have a cloud-only environment in Okta that you want to migrate over to OneLogin, or you may have a Traditional Hybrid IDaaS Architecture in place that you want to take the opportunity to move away from. For this scenario, we have two recommended options to allow your organization to perform a cloud-to-cloud based user migration (both include the migration of Okta passwords, when required).

1. OneLogin Smart Hooks User Migration Hook

With this approach, you can have your users drive the migration of their account simply by instructing them to sign into the new OneLogin environment using their existing Okta credentials. There is no requirement for any additional software to be deployed on premises or any kind of intermediary SaaS automation solutions in the middle to perform the cloud-to-cloud based user synchronization. The only thing required is to implement a user migration Smart Hook on your OneLogin environment. The Smart Hook will run as a fully customizable serverless JavaScript function which will be hosted on our platform on your behalf. It will execute an API call to Okta each time a login request is received for a user which does not currently exist in the OneLogin cloud directory.

The steps you will need to take include:

1. Define the logic required to be contained in the Smart Hook.
2. Define the mapping of user attributes sourced from the Okta API (post successful authentication from the user) into OneLogin standard and custom fields. This will control how attributes are mapped when the new user is created in OneLogin from the Smart Hook.
3. Implement the Smart Hook in a test environment and validate the function is working as expected.
4. Deploy the Smart Hook to the production environment and initiate your communications to users to sign into the new OneLogin environment with their existing Okta credentials to create their new account.
5. Remove the Smart Hook once all required users are migrated.

To assist with this approach, we have published an example Okta User Migration Smart Hooks in our public GitHub repo. You can also watch the video below to see how this user migration process works.

2. OneLogin Inbound SCIM Provisioning

With this approach, you can enable an inbound SCIM interface for your new OneLogin environment which can be used to create/update/delete users from any SCIM compliant client systems. It is simply a case of using the App provisioning capabilities built into your Okta solution to outbound provision your users out of Okta and into OneLogin. This solution can be configured to include the current Okta password in the SCIM payload sent to OneLogin or exclude it if required.

The steps involved in this approach are:

1. Enable the inbound SCIM interface for your OneLogin environment by engaging with your account manager.
2. Create a SCIM provisioning application in Okta to connect to your SCIM endpoint for your OneLogin environment.
3. Define the relevant attribute mapping on the SCIM Application in Okta and provision some test users to your OneLogin environment. Validate the test users.
4. Update the SCIM Application in Okta to provision all required users in your Okta environment to OneLogin. Review your OneLogin environment to ensure the number of users matches the expected outcome and initiate communications to instruct your users how to sign in to the new OneLogin App Portal with their existing Okta credentials and how to configure the required MFA factors on their OneLogin account.
5. Delete the SCIM Application in Okta and disable the SCIM endpoint on your OneLogin environment once all required users are provisioned.

We will be publishing a new KB article in the coming weeks outlining the detailed steps required to configure the inbound SCIM solution.

As you can see, there are three straightforward ways in which you can get your users into OneLogin as part of your project to migrate from Okta. Once you have your users loaded into OneLogin and the relevant authentication factors set up, you can then start to plan how to approach your application migration, which is the topic for part two of this blog series. Stay tuned for more on that soon!

The post User-Centric Identity: Ensuring a Seamless Migration to OneLogin appeared first on OneLogin Identity Management Blog.

In the current cyber threat landscape, where online security is paramount, the threat of session cookie replay attacks looms large. These attacks sidestep the conventional need for credentials and aim to hijack your online sessions, potentially compromising sensitive data and taking over user accounts. This blog post delves into the intricacies of session cookie replay attacks, shedding light on what they are, how they work, and the potential consequences they can unleash. Understanding these attacks is the first step in fortifying your online presence and ensuring the safety of your organization’s digital identity.

Understanding session cookie replay attacks

A session cookie replay attack is a cyber-attack that attempts to take over a particular user account without the need for the credentials associated with that account. That sounds pretty scary – how can that be? While identity-based attacks typically involve trying to validate or steal credentials, session cookie replay attacks focus on maliciously replaying a session cookie to a targeted web service. To fully comprehend the workings of this type of attack, it’s essential to have a solid grasp of how session cookies function.

A session cookie is a small digital marker stored in your web browser, allowing a website to customize the content it shows you. To give you a clear example of this customization, think of a scenario where a website serves specific content only after verifying your session, which is typically established during the user authentication process.

Now, imagine an attack that aims to acquire this session cookie and then use it to impersonate you on the targeted website, all from a different computer controlled by the attacker. This action of replaying the session cookie isn’t particularly complex and can be accomplished by importing the cookie into most popular web browsers using simple browser extensions. It is important to note that this doesn’t require sophisticated nation-state-level hacking tools.

Attackers employ several methods to acquire these valuable cookies. They may deploy malware on infected machines to collect cookies directly from web browsers. Alternatively, they might execute Man-in-the-Middle attacks, intercepting cookies from users by using a malicious server that sits between the user’s browser and the target service. Lately, we’ve also seen attackers compromise technical support systems, which conveniently contain recently-exported session cookies from users, originally intended for legitimate troubleshooting purposes.

How damaging can these types of attacks be?

In the simplest case, the user’s account in the targeted service can be taken over by the attacker, the user may lose access to that web service, and their sensitive data may be compromised. So that’s bad, but the blast radius from this kind of attack gets much larger if the targeted service is actually an Access Management solution providing single sign-on (SSO) access to multiple integrated services. That one session cookie can be the only thing needed to access hundreds, if not thousands, of systems integrated to trust the Access Management solution.

The blast radius can be even worse if that session cookie is associated with a user that has some type of administrative privilege on the targeted Access Management solution. In that situation, the attacker has the potential to not just overtake the user account associated with the cookie, but ultimately the entire Access Management system. At the same time, it can be used to impersonate any of the organization’s users in any of the integrated systems.

If I’m using FIDO2 MFA, I’m safe right?

Well, unfortunately, not quite. This attack relies on replaying a session cookie that’s already stored in the user’s browser. This means that the entire authentication process has already been successfully completed, and it doesn’t matter which type of MFA was used in that process. The authentication is essentially a thing of the past at this point.

Securing your Access Management solution

The key measures to defend against such attacks primarily focus on preventing the session cookie from falling into the wrong hands initially. These steps encompass security-awareness training, using endpoint protection software, implementing FIDO2-compliant Authentication Factors, controlling access to MDM-managed devices, implementing Adaptive Authentication, conducting security monitoring, and ensuring the safe handling of sensitive data, such as session cookies, when shared during technical support processes.

Once an attacker has acquired and replayed a session cookie against your Access Management solution, your focus should shift to detection and swift responses. It’s crucial to have a well-established response plan in place, particularly when there are signs of privilege associated with the targeted account within the Access Management solution.

For detection, your organization should set up rules within your SIEM (Security Information and Event Management) environment to identify irregularities, such as disparities between login events and suspicious post-login patterns for the same account. This can include unusual IP addresses, locations, or activity patterns.

When responding to such incidents, the minimum actions should involve disabling the compromised account to terminate all active sessions. Additionally, a thorough forensic examination of the activities conducted by the attacker with the stolen session cookie is essential. Engaging with your Access Management vendor for support can be valuable, as they may provide further information to aid your investigation and ongoing response efforts. Having a well-documented run book to follow during such incidents is vital for a timely and effective response.

How can organizations using OneLogin Access Management solutions protect themselves against session cookie replay attacks?

• Never assign privilege in your OneLogin production environment to standard/daily use user accounts. To put it simply, the more often you use an account, the higher the likelihood of it being abused by a session cookie replay attack. Reduce your risk exposure by allocating privilege to separate accounts, typically used less often than standard accounts, and thus lowering the chances of a session cookie with admin rights falling into the wrong hands. By providing separate accounts, this also allows you to assign more stringent security policies to these accounts, without impacting the day-to-day user experience of your Admins who also need to use the platform’s SSO capabilities.

• Automate the allocation of OneLogin user security policies to your separate Admin accounts using our Mappings capability by assigning groups (which have user security policies attached) based on conditions you define and maintain in your Mappings rule base. Ensure that session lifetime settings for high value admin accounts are configured to terminate after a maximum of 30 minutes. This change increases the difficulty for attackers in two ways: first, they must quickly obtain and transfer the session cookie to their attack machine, and second, they have limited time to maintain access with the stolen session cookie, if they can successfully replay it.

• Make certain you have a strongly controlled authentication factor registration process for Admin accounts and require at least two FIDO2 compliant factors to be registered for each admin account. Define a process to control how and when authentication factors can be registered by your users to their admin accounts. Furthermore, require admins to register two separate authentication factors against their admin accounts so in the situation where access to one authentication factors is lost, they can still access the OneLogin platform.

• Consider using our app policy “forced authentication” capability to break the SSO experience into specific high value applications just for your separated admin accounts. Should an attacker somehow acquire a valid session cookie for one of your isolated admin accounts and attempt to access an integrated application through the OneLogin portal, they will be forced to re-authenticate in order to access the target application. Their attempt to use the existing single sign-on (SSO) session will be unsuccessful. The stolen session cookie cannot be reused to bypass this request for a fresh authentication, as it is required in order to fulfil the application policy requirements.

• Maintain at least two “break-glass” accounts (the Account Owner User and one Super User account) which are tied to a corporate-owned group mailbox owned by the IAM team. These two accounts are the key components needed in any recovery plan in the event of a significant security or BCM incident. To safeguard the authentication factors linked to these critical accounts, often referred to as the “keys to the kingdom,” it is advisable to store them offline within a physical safe. This practice guarantees protection against online attacks, and it assures a reliable means of regaining access to your OneLogin environment, should you lose standard administrative access.

• Reduce the number of “ClickOps” admins who require access to your OneLogin production environment by leveraging IaC (infrastructure as code) approaches to configure and manage this environment. For example, a great way to achieve this is through using IaC approaches where the configuration for the most important components of your OneLogin service are stored as code in a secured GIT repository. Using this approach also allows an organization to reduce configuration drift between Production and Non-Production environments. This means that changes can be carried out first in a Dev/Test environment using an account with admin rights in that environment (via the admin console) to manually apply the change. Taking this approach also brings the added benefit of significantly reducing the number of admin accounts needed on Production as most changes will be applied programmatically to the environment via the OneLogin Admin API and in a controlled manner (e.g. once a week during a planned change window).

• For the remaining users still requiring admin privileges on your Production environment, leverage OneLogin’s fine-grained Delegated Administration capability to only allocate the exact privilege the user needs and nothing more. By adhering to the principle of least privilege, you can reduce the level of admin privileges granted to the account in question, minimizing the impact if a session cookie replay attack were to occur.

• Ensure the lifecycle for managing your separate OneLogin administrative accounts is tied to your current JML process for standard accounts. You do not want separate admin accounts associated to an employee that has left the organization or changed roles lingering around in your environment. As a standard, these should be disabled and removed during any JML events.

• Automate the allocation of OneLogin privileges to your separate Admin accounts using the OneLogin Mappings capability by assigning roles (which have delegated admin privileges attached) based on conditions you define and maintain in your mappings rule base. Our Mappings capability should be ideally managed and maintained by Terraform. With this approach you can ensure your mappings rule base always meets your desired state as defined in your configuration code in your GIT repository. Any mappings changes made directly to your environment via the Admin console (for example, by an attacker) will be automatically reconfigured to your desired state by scheduled Terraform runs.

• Configure a Passwordless policy and require FIDO2 compliant authentication factors at all times for all Admin accounts. Supplement this with Device Trust and IP address-based controls to further secure how and where admins can sign into the OneLogin platform. By implementing FIDO2 authentication factors, the risk of session cookie theft is minimized, as users won’t be able to complete the authentication process necessary to obtain session cookies when they are unwittingly directed to the OneLogin service via a malicious proxy. To strengthen security even more, consider limiting admin account access to specific locations, such as only allowing it from managed devices, dedicated management servers within your network, or through PAM Isolated browser environments.

• Enable Adaptive Authentication and, in particular, Smart Access on the user security polices allocated to all Admin accounts. With Adaptive Authentication in place and finely tuned for your admin users, you can reduce the attack vectors that can be leveraged by attackers to steal session cookies.

• Do not associate your Admin accounts with AD or any on-prem IdP in any way. With the ever-expanding array of attacks directed at Active Directory it makes perfect sense not to involve AD in your separated Admin accounts either from an authentication or directory sync perspective. This also aligns with Microsoft’s own advice on how to secure a Hybrid Cloud identity solution.

• Stream all OneLogin events to your SIEM/CASB platform using our webhooks capabilities or use our events API to periodically pull events in. Ensure events indicating privileged admin activity which are performed from unusual IP addresses outside of your organizations network boundaries are alerted upon and investigated immediately.

• Enable custom email notifications to be sent to users when privileged activities have been performed on your OneLogin environment from their respective admin user accounts. If users receive email notifications indicating activities performed which they do not recognize, they can immediately alert your security team to investigate and respond accordingly.

Final Thoughts

Session cookie replay attacks pose a considerable risk to digital security, allowing cybercriminals to exploit an unsuspecting user’s session information to impersonate them on a targeted website. The potential consequences are far-reaching, from compromising individual accounts to potentially gaining control over an entire Access Management system. While no security measure can be foolproof, a multi-faceted approach that combines strong user authentication, privilege management, monitoring, and rapid response can significantly reduce the vulnerability to session cookie replay attacks. Organizations must adapt and evolve their security strategies to stay one step ahead of these threats, ensuring the integrity and safety of their digital ecosystems.

Stay tuned for the second blog in this series where we will discuss how to supplement all of the controls outlined here with additional capabilities from One Identity Safeguard (PAM) and Identity Manager (IGA) solutions.

The post Defending Your Organization Against Session Cookie Replay Attacks appeared first on OneLogin Identity Management Blog.

Welcome to the second part of our blog series on the state of passwordless authentication. In the first blog, we focused on the new kid on the block, passkeys, and how this emerging technology will likely have a significant impact to the advancement of the identity and access management industry’s desire to finally eliminate passwords for good.

In this blog, we are going to look at alternative options which can be used if passkeys are never going to be an option for your organization or if you need to implement a passwordless solution for the short/medium term. This maybe be the case if you’re waiting on the passkey technology to mature a little more, or if you’re going through various digital transformation projects within your organization which will then open the door to modern technologies such as passkeys.

Getting a better understanding of passwordless

When we talk about passwordless solutions, we are essentially talking about using authentication factors which were traditionally associated with providing a multi-factor authentication (MFA) solution. That is, of course, usually supplementing the username and password authentication factor with additional authentication challenges such as a time-based one-time password (TOTP), a mobile app push notification, a physical security key, etc.

OneLogin supports a wide range of authentication factors that can be used for MFA use cases. These factors can be used in a traditional flow (e.g., after a username and password combination) or in a brute force protection flow (e.g., first an MFA factor followed by username and password combination). The good news is that the OneLogin platform also allows you to use any of the available MFA authentication factors for your organization’s passwordless solution.

Defining user security policies in a passwordless solution

Controlling your end user’s authentication experience with OneLogin is simply a case of defining a user’s security policy which is configured to meet your requirements and then allocating this policy to your users. There is always a one-to-one relationship between a user and a statically assigned user security policy. This makes it very easy to identify not only the current experience each user will be presented with, but also to change that experience by just assigning them an alternative policy.

The allocation of a user security policy to a user can be fully automated using the OneLogin mappings capability. Mappings will typically be used to allocate a OneLogin group to a user (based on rules defined in the mappings rule base) and this group will have a user security policy attached to it. You can configure this in the Admin Console, or you can also apply your mapping rules programmatically (pro tip – Try the OneLogin Terraform provider!) via the OneLogin mappings API.

One of the most significant configuration items in the user security policy is the sign-in flow, which offers three modes of operation. One of those modes is the passwordless sign-in flow. When this is enabled on a policy it simply means the end user will never again see the dreaded “Username and Password” dialog box we all love to hate. One little tick of a box and no password prompts ever again! Absolute bliss!

So, before we go rushing off to tick this box we need to think about a couple of things. The first thing we need to decide is what are we replacing the dreaded password with? As mentioned above, we have a wide range of authentication factors available on the OneLogin platform that can be selected to meet your specific needs. We will dive into some of these available options a little later in this blog. The next thing to consider is how and when we will allocate these new user security policies providing the bliss to your users. The main pre-requisite here is making sure that all your users have already registered the required authentication factors you want to use in your solution as you cannot allow registration of the required authentication factor within a passwordless user policy just requiring that factor itself because… well, that just wouldn’t be too secure now, would it?

You can also fully pre-register certain authentication factors on behalf of your users if you have trusted information you know to be correct such as a verified email address or verified mobile phone number if you want to use the email or SMS authentication factors in your passwordless solution. By pre-registering these authentication factors on behalf of the user, this means they will have an authentication factor configured against their account (and without any end-user involvement) which is all ready to go and the door to start using those blissful user security policies is opened wide. Alternatively, you need to allocate user security policies with the traditional, username and password followed by MFA, sign in flow to your users for a period of time to allow secure registration of the relevant authentication factors you would like to use in your passwordless solution.

Migrating to passwordless for increased protection and a better user experience

Now, you have reached the stage where you know which authentication factors you want to use in your passwordless solution, and all your users have registered such factors to their accounts, but how can you migrate to the new passwordless user experience to make the bliss a reality? Well, there are two options which you can take depending on your appetite for automation.

The first option is the “Admin-driven” approach whereby your OneLogin Admin team will need to initiate the process of switching user security policies assigned to users when it is fully confirmed that they have the required authentication factors registered against their account. This process can be semi-automated using the mappings capability mentioned earlier in this blog, but ultimately a OneLogin Administrator needs to trigger the re-assignment of the statically assigned user security policy when it is validated that a particular user is “ready to go” for the move to passwordless life.

The second option is to allow the OneLogin extensibility capability known as Smart Hooks to do the challenging work for you. With this approach, you can use the Pre-Authentication Smart Hook capability to dynamically apply an alternate user security policy to a user based on elements of the “context” of the incoming authentication request to the OneLogin Platform. The key to this approach is leveraging the “MFA Devices” context which is made available to the Smart Hooks service each time an authentication request starts. This context will provide a list of registered authentication factors for the specific user starting the authentication flow to the Smart Hooks service so that this information can be evaluated in the conditional logic you can include in your Pre-Authentication Smart Hook Java script function.

So, you can use this approach as your own customized “passwordless policy allocation engine” whereby your conditional logic will determine which passwordless policy is allocated to a particular user based on a wide variety of factors. You can also keep this logic extremely simple for simple requirements or as complex as you need and even store the whole Smart Hook configuration as code in your version control system and deploy it using DevOps approaches each time you need to make a change to the logic, if that is your preferred mode of operation. We have recently released a new public GitHub repository containing various automation solutions and within it you can find samples of Smart Hook configurations which you can use as starting points for your own implementation. You can learn more about the OneLogin Pre-Authentication Smart Hook here.

Watch this video to see how the OneLogin Smart Hooks capability can control the passwordless authentication user experience based on authentication factors registered to a user.

Taking an advanced authentication approach: Combining passwordless and adaptive authentication

Now that you have fully implemented the migration to your passwordless solution for all your users, what else can you do to improve your security posture against those persistent threat actors that may still try to attack your users even when the weakest link of the password has been removed from the equation? Well, you can supplement your solution with other security controls from the OneLogin Platform of course!

There are two main additional controls you can layer on top of your passwordless solution to move towards advanced authentication. These controls may be used independently or together – it depends on what works best for the needs of your organization. The first additional control you can apply is layering OneLogin’s adaptive authentication solution, SmartFactor Authentication. It uses machine learning to analyze a broad range of inputs, such as location, device, and user behavior, to calculate a risk score and determine the most appropriate authentication flow and security action to take for each login attempt. Depending on the detected level of risk, SmartFactor Authentication adjusts the authentication factors needed to log in. For example, it can dynamically switch the user (Smart Hooks is the master here!) into a different passwordless-based user security policy (which may require a less convenient/higher friction authentication factor) based on a calculated elevated risk level.

The second additional control you can layer on top of your passwordless solution is the OneLogin App Security policy capability. By using this capability with your passwordless solution, you can mandate that an additional passwordless authentication factor (different from the one required by the user security policy level) is required to access either specific applications integrated into your OneLogin environment or all applications. By using this approach, you can “chain together” two completely separate authentication factors into your combined passwordless solution where security requirements may be significantly high. You can also join the adaptive authentication and OneLogin App Security policy approaches together to only block access to specific high value applications if the risk level exceeds your risk threshold.

Pros and cons of native OneLogin passwordless authentication factors

We will now look at the pros and cons of some of the authentication factors available when using OneLogin and adopting passwordless.

OneLogin Protect

Details: OneLogin Protect is our free mobile solution that allows users to submit their one-time password (OTP) by pressing a button. Available on iPhone and Android.

Pros: Convenient tap and approve mobile app experience for users. Can enforce additional controls around mobile device security posture (e.g., require screen lock and/or biometrics, block jailbroken devices).

Cons: Access to mobile phone is required. Organization policy may require corporate managed mobile is provided to all staff. Organization may face resistance from users to install a “work app” on personal phone. It can be bypassed by advanced attacks such as man-in-the-middle (MITM) attacks or become the target of push notification storm attacks.

Summary: OneLogin Protect is a great candidate for a passwordless authentication factor for your workforce solution where your users have access to a smartphone at all times. You may wish to layer additional authentication factors on top of it, using the OneLogin App Policy capability for particularly sensitive environments or specific applications. It is not a good fit for CIAM solutions as customers are unlikely to want to install yet another mobile application on their phone.

OneLogin SMS

Details: A one-time password (OTP) is sent to the mobile phone number associated with a user over SMS.

Pros: It is a convenient solution for users that can access a mobile phone with cell network connectivity at all times.

Cons: Requires copying or typing a 6-digit code (Note: It can be less inconvenient if the user is using their mobile device anyway to access a service.) Can be bypassed by advanced threat actors like SIM swapping, carries a cost per authentication, requires an SMS Gateway provider.

Summary: OneLogin SMS is a good authentication factor for CIAM passwordless use cases, but does mean additional cost for the CIAM solution. For workforce identity, this authentication factor could be a good fit for limited use cases until a stronger authentication factor is available for the user. For example, a new user signs in for the first time via SMS. Then, the user is forced to register a stronger authentication factor which would be used for all subsequent authentication requests.

OneLogin Email

Details: OneLogin sends an automated email to the user’s email address to authenticate the user.

Pros: Convenient solution for users that can access a non-corporate email account at all times. The Magic Link option provides a better user experience compared to the OTP copy/type process.

Cons: Assumes the registered email account of the user has not been compromised which may not be the case.

Summary: This is a good authentication factor for CIAM passwordless use cases where security requirements are not particularly high, especially with the Magic Link approach. Similar to OneLogin SMS, this authentication factor could be a good fit for very limited use cases until a stronger authentication factor is available for the user.

Additional passwordless authentication factors

OneLogin also offers several authentication factors leveraging external partner solutions which can be used in your passwordless solution. These include factors like legacy YubiKeys, Google & Microsoft Authenticator Apps, Duo Security and the ability for OneLogin to act as a Radius client to an External Radius server solution. While some of these solutions may fit niche use cases in your passwordless solution, we recommend that any organization in the process of designing a new passwordless strategy should prioritize the native OneLogin provided authentication factors mentioned above (along with Passkeys as mentioned in our first blog of course!).

Organizations should also factor into passwordless design considerations the newest authentication factor made available on the OneLogin platform – the BYOD MFA/Trusted IDP as a factor capability.

The post From friction to freedom: Automating Passwordless Authentication appeared first on OneLogin Identity Management Blog.

Today, we are publishing part one in a four-part blog series on the state of passwordless authentication in the year 2023. This first blog will focus on the newest kid on the block which is, of course, Passkeys. Following Google’s announcement around Passkey support for their consumer accounts (Passkeys: What they are and how to use them), it seems like the wait for widespread adoption opportunities of the long-anticipated extension to WebAuthn is finally over. 

What are Passkeys?   

Passkeys are an extension to the WebAuthn standard, which takes the same great user experience of being able to use device-based biometrics to authenticate to web applications and makes this capability portable across multiple devices. At OneLogin, we have supported WebAuthn as an authentication factor on our platform since 2019. The convenience of using this factor to authenticate to access-protected resources is unmatched by any other solution out there. However, the complaint from adopters, up to now, was always the same: “I can only use this factor on the device where the credential was registered. What happens when I also need to use another device without a biometrics capability?” That’s where passkeys come in.  

Passkeys can be used anywhere by syncing an encrypted version of the Passkey across all of your devices on a single platform (e.g., Apple) and for any devices you need to use that are either not part of that platform or where Passkeys are not yet available, you can use a Passkey stored on your phone to authenticate to the particular service by simply scanning a QR code and performing touch ID/face ID to trigger the sharing of the Passkey to the other device (this happens over Bluetooth, which brings in another security control – proximity).  

For full details on what Passkeys are and how they work, please see the excellent information available from the FIDO Alliance organization.  

OneLogin Passkeys support 

We are pleased to announce that OneLogin customers can now leverage Passkeys to authenticate to protected resources via our existing WebAuthn authentication factor. Passkeys can now be used to authenticate to access-protected resources as a second factor in a traditional sign in flow, the first factor in a brute force protection flow or as the only factor in a passwordless flow. The registration of the Passkey must take place on a supported operating system. To use the Passkey to authenticate to OneLogin, a supported browser must be used. For a full matrix of supported devices, visit the Passkeys.dev site.   

Passkeys are not a perfect solution for every environment (if ever such a thing existed!) as there are many cases where they probably will never be leveraged (i.e., devices with Bluetooth disabled/blocked, legacy operating systems, virtual desktop environments, environments where mobile phones are not permitted, etc.), but we think this capability will eventually be a significant game changer in the drive to increase adoption of passwordless authentication solutions, particularly in the Customer and Identity Access Management (CIAM)/consumer space.  

Stay tuned for some new KB articles in our knowledge base on how to set up and use Passkeys with OneLogin. 

Benefit now from Google Passkeys with OneLogin Trusted IdP  

As mentioned at the beginning of this blog, the announcement from Google on the launch of their Passkeys capability is also significant for application owners who allow social sign up and sign in to their applications using Google as an identity provider. Applications using OneLogin for their CIAM solution can now also benefit from the rollout of Passkeys to Google accounts, courtesy of our Trusted IdP capability. The rollout of Passkeys to Google consumer accounts now makes it even easier for new users to sign up and sign in to any CIAM applications using OneLogin, as our existing Social Sign-in integration to Google via our Trusted IdP capability fully supports the use of Google Passkeys. 

Below is an example of how the user experience looks for a new user signing up for a CIAM application using their Google account and a Passkey via the OneLogin Trusted IdP capability.  

In this second example, we show the experience of a user using their existing Passkey with Google and then registering a second Passkey with OneLogin in a fully passwordless authentication flow. 

Why not try out the OneLogin Trusted IdP integration to Google with Google Passkeys for yourself? Please visit our new CIAM Demo application https://cedarstonedemo.com. (Change the App Configuration to the “Gaming” App Theme in the bottom left corner and select “Sign In” and the “Sign Up with Google” option will be visible.)  

Migrate your users to Passkeys with OneLogin 

Customers already using the OneLogin Platform for their CIAM solution can enable Passkeys into their existing service without changing a single line of code in your application (assuming the integration for Auth is via OIDC/SAML flows and not API-based).  

Existing users who currently use a password to authenticate to your service can be presented with an optional Passkey registration prompt, which can be accepted by the user or simply rejected if they prefer to continue to use their password. If a user accepts the Passkey registration offer, they will be guided through the process to register a Passkey on the device they are using or can chose to store the Passkey for your service on their mobile device. Once the user has registered a Passkey against their account in the OneLogin environment supporting your application, you can then look to our Smart Hooks capability (Pre Auth Hook) to dynamically switch the user to a passwordless user policy in OneLogin the next time they try to log in to your service. This is achieved by implementing some simple logic in your Smart Hook, which will leverage the contextual information that is available to the service (e.g., Multi-Factor Authentication (MFA) devices registered to the user) and, based on this, switch the user into the relevant user security policy in OneLogin, which requires the WebAuthn/Passkeys authentication factor with a passwordless sign in flow. 

For new users registering to your application for the first time, you can allow them to create an account with a password and give them the option to migrate to Passkeys, just like above. Alternatively, you could allow new users to register as passwordless from the start. Currently, we support the ability to pre-register an MFA factor for a new user with either SMS OTP (One Time Password) or email OTP/magic link. So, new users can be created as passwordless users in your service with either of these two available factors. These users can then be prompted to register a Passkey to their account via an application security policy that can be assigned to the CIAM application. Once the Passkey factor has been registered to the user, our Smart Hooks capability can leverage this information from the available hook context so that the next time the user tries to sign in, they will be directed to a passwordless user security policy that requires Passkeys rather than SMS OTP or email. 

In all cases above, you can phase the rollout of Passkeys’ passwordless capability using policies scoped on groups of users, or if you prefer, you can opt for a “big bang” approach and enable the option for all users. 

Don’t miss the next part of this blog series where we will discuss all the passwordless options currently available natively in the OneLogin platform and identify the best fit for a new CIAM application deployment. 

The post Say goodbye to passwords: The rise of Passkeys appeared first on OneLogin Identity Management Blog.

Today, we are pleased to announce the launch of the first in a series of new Identity Proofing integrations with our new integration to the Jumio KYX Platform for Identity Verification services.

This integration, which is powered by our OneLogin Workflows solution, brings Identity Verification capabilities into the OneLogin Self Registration experience. OneLogin customers can now enhance their existing Self Registration experiences to ensure that new users must successfully complete Identity Verification before being issued with an Invitation to establish their account in OneLogin.

The solution allows organizations to tie digital identities to real world identities using government issued identity documentation along with selfie and liveness checks which can help an organization meet its compliance requirements and further strengthen the security posture of their OneLogin implementation.

The Self Registration Case

The integration, powered by OneLogin Workflows, ensures that users are sent an Identity Verification request email to the email address which has been already verified in the first step of the standard OneLogin Self Registration process.

When a user requesting a new OneLogin account receives this email they will be asked to click on a URL to commence a particular Jumio Identity Verification workflow which has been mandated by an organization through their solution configuration.

When the user clicks on the URL, they will be brought into the Jumio Identity Verification service to scan and upload their government issued identity documentation along with a selfie with liveness check functionality.

The user can complete the ID verification process on a desktop with a webcam or switch to a mobile device to complete the process.

The integration solution will then poll the Jumio service for the results of the Identity Verification operation. If successful, the account will be automatically approved for creation in OneLogin, and an invitation email will be sent to the user to complete the OneLogin Account creation process.

If the Identity Verification operation reports a negative result, then the account creation process is suspended. An organization can then decide to either automatically delete the requested account or inform the user via email to contact a support desk for assistance and manual verification, if required.

Self-Registration with Identity Verification Benefits

The solution brings immediate benefits to CIAM (Customer Identity and Access Management) use cases which may exist today without any form of Identity Verification in place or where Identity Verification is performed via labor-intensive manual processes. The solution also ensures a strong MFA (Multi Factor Authentication) registration capability so that CIAM implementations can ensure new users validate their real-world identity before being allowed to enroll for MFA or even create a password for their account in the CIAM solution they wish to access.

From a workforce perspective, this solution offers the ability to automate certain steps of the traditional HR (Human Resources) onboarding process for a new hire and brings Identity Verification capabilities to B2B and partner/contractor scenarios which may not be covered sufficiently by B2B federation capabilities or existing onboarding processes today. It can also be used to verify the Identity of potential new hires at the applicant stage to ensure no sensitive company information is disclosed to a malicious actor posing as a candidate for an advertised vacancy.  An organization may wish to have the identity of new applicants verified by this integration. They could then leverage the OneLogin Workflows or Universal Connector solutions to create the user in the target HRIS system and update attributes used to track whether Identity Verification has already been completed. We are excited to see all the diverse ways this integration can be used by our customers. 

Re-Verify your Users

In addition to the capabilities mentioned above, the solution also allows for Identity re-verification workflows to be triggered for users that were put through the Identity Verification process when their OneLogin account was first created. The Identity re-verification workflows can require a user to perform another selfie and liveness check which can be verified against the Identity documentation previously submitted by the user at the point of account registration. These Identity re-verification workflows can be triggered based on timebound requirements (re-verify once per quarter, etc.) or based on login risk events and even as part of a role change for a user within OneLogin.

Conclusion

In today’s world, a user’s identity is key to their security access, thus Identity verification before a user’s account is created is becoming a core component of a secure solution. We have all gotten used to providing additional authentication factors when we log in to a system. This login verification ensures that the person logging in is the person who created the account, but it does not ensure that the person who created the account is who they claim to be. Identity theft is prevalent. It is incredibly easy for bad actors to go about creating accounts using other people’s names and information. By implementing an Identity Verification process before your users even create their accounts, you can ensure they are who they say they are and prevent bad actors from getting in. We are incredibly excited to add this capability to our One Identity Unified Identity Security solution.

The post OneLogin with Jumio Identity Verification appeared first on OneLogin Identity Management Blog.