March 8, 2024 | IBM i

What is IBM i Single Sign-On (SSO)?


Single sign-on (SSO) is an authentication and authorization technique where a user can log in and access multiple IBM i and other servers/applications using a single set of login credentials. SSO eliminates the need of managing multiple passwords across multiple servers. It also reduces the risk of unauthorized logins due to weak or reused passwords. 


SSO authorizes users to access multiple servers/applications by pairing a network authentication server with an Enterprise Identity Mapping (EIM) domain. SSO uses the following components to reduce the number of logins that are required to access multiple IBM i servers/applications.   

  • A Key Distribution Center (KDC) running inside a Kerberos server or a Network Authentication Service (NAS), which is IBM’s implementation of the Kerberos authentication protocol. The KDC is typically hosted on a Windows Active Directory (AD) server or inside the IBM Portable Application Solutions Environment for i (PASE for i). The NAS/Kerberos server functions as a central Identity Provider (IdP) service that authenticates users and issues digital security tickets (tokens) verifying their identity.  
  • Enterprise Identity Mapping (EIM) domains and IBM i directory servers which accept Kerberos tickets, map user profiles and specify identity mappings for access to authorized IBM i servers & applications. With a valid Kerberos ticket, the user can access any servers or applications they are authorized to in an EIM without entering additional IBM i credentials.  

By decoupling authentication and authorization services, SSO allows users to access IBM i and other operating system applications/servers using Kerberos authentication and EIM user profile mappings.  


Please note that although we are referring to IBM i SSO solutions in this blog, SSO can also be used to provide access to other server and application environments including Windows and Linux servers. 


An IBM i SSO solution can be complex to configure (figure 1). Check IBM’s Configuring single sign-on and the How to Configure IBM Navigator for i for Single Sign On (SSO) website for more information on setting up IBM i SSO access.  

Figure 1: There are several steps to setting up an IBM i SSO solution including configuring the Network Authentication Service (Kerberos) on IBM i

Advantages of using IBM i SSO

IBM i SSO reduces the number of user passwords required for i server access. Implementing IBM i SSO helps reduce user password fatigue, reduce user password support costs (fewer assisted password resets) and increases productivity through fewer user profile lockouts. 


SSO creates a streamlined login environment with a single-entry point for multi-server authorization. Single-entry authorization narrows SSO attack vectors and simplifies the user login experience.  

Can IBM i SSO use MFA for increased security?

IBM i SSO environments may also be able to incorporate multi-factor authentication (MFA) for user verification. Combining MFA authentication with SSO creates a stronger security posture for multiple IBM i server/application access. An SSO-MFA combination balances the convenience of SSO (one set of credentials allowing access to many servers/applications) with the security of MFA (ensuring that the person signing on with their credentials is indeed the person who owns that identity).  


If Kerberos authentication uses MFA, it may satisfy MFA requirements for associated IBM i EIM systems. You should check with your auditor or security architects about the best way to enable SSO logins to satisfy IBM i MFA.  

IBM i SSO as a single point of failure & security risk

Single-entry authorization creates a single point of failure. An SSO failure can disable user access across multiple systems. SSO failures may be mitigated by configuring SSO to run in a cluster with load balancing, if available.  


SSO’s single point authorization can also affect security setups. In the case a bad actor steals an SSO user’s credentials, they would be able to access several different servers/applications. In some regards, SSO is a bigger security threat than requiring users to individually login to each of their authorized servers/applications. 

Can IBM i SSO satisfy Federal Zero-Trust Architecture (ZTA) requirements? 

It is unclear whether SSO can satisfy requirements for the US government’s ZTA strategy that requires agencies to meet specific cybersecurity standards and objectives by the end of fiscal year 2024. Using SSO for multi-system access could conflict with ZTA’s foundational tenets (figure 1) including: 

  1. Continual verification of each user, device, application, and transaction: SSO uses a verify once, allow multiple logins model whereby a user authenticates to a NAS and is then allowed to access multiple servers and applications using a digital security ticket (token).  It’s unclear whether ZTA will accept using tokens as a means of continual verification. 
  2. No actor, system, network, or service is trusted: It could be argued that SSO-enabled IBM i servers are implicitly trusting the Kerberos service for verification and that trust may conflict with this tenet. 
  3. Anything & everything attempting to establish access must be verified: It is unclear whether an IBM i server allowing user logins based on Kerberos tokens will qualify as verified access. 
Figure 2: Foundational Tenets of ZTA

However, in its Moving the U.S. Government Toward Zero Trust Memorandum, the U.S. Office of Management and Budget (OMB) specifies that “Agency staff use enterprise-managed identities to access the applications they use in their work…” As described above, IBM i SSO employs an EIM domain and IBM i directory servers that accept Kerberos tickets to map user profiles and provide identity mappings for authorized IBM i access.  


The result is that it’s unclear whether IBM i SSO will satisfy Federal ZTA guidelines. One part of IBM i SSO may conflict with the Federal guidelines (using tokens for authentication) while another part seems to fulfill them (using EIM for authorization). To resolve any confusion, check with your security architects or stakeholders to determine if IBM i SSO implementations will be covered under Federal ZTA requirements. Check out SEA’s What is Federal Zero Trust Architecture (ZTA) & How Will It Affect My IBM i? blog post for more information on ZTA.  

Getting started with IBM i SSO 

This blog post provided background on what IBM i SSO is and information on how to get started with IBM i SSO. At SEA, we always wish you continued success with your IBM i security initiatives.