The majority digital workplaces are private. Access is only permitted to members, and visiting any page requires you to log in, and have a valid Igloo session. However, there are a lot of different ways to manage identities and passwords in Igloo, and across other identity services you might employ. The platform is designed to accommodate a diverse array of use cases, to fit seamlessly into your existing identity management architecture. 

Igloo Authentication

The default login method is to use the native Igloo authentication. Your username and password are stored in Igloo. In the event of an issue with an account, Workplace Administrators can trigger a password reset from the Manage Members area, and members can use the Forgot Password link to do the same. Igloo passwords are also used to create sessions with the Igloo APIs, making them essential for developers and ILST administrators. 

Single Signon

More commonly now, customers already have an Identity Provider and Igloo integrates with it, using single signon through SAML 2.0. With single signon, passwords are managed directly in the Identity Provider, such as Okta or ADFS, and are never sent over or stored in Igloo. Instead, the Identity Provider verifies member credentials on its own, and sends a certificate that lets the platform log them in. 

A single signon solution has several advantages. If you're using multiple services, including multiple digital workplaces, it can ensure that members only have to log in once, and the Identity Provider carries their session with them wherever they go. Through the Identity Provider, you're also able to enforce additional password policies, such as password expiry, complexity requirements, and even two-factor authentication. 

Passwords and the ILST

There's a password question that consistently comes up around the Igloo LDAP Sync Tool, used for managing members directly from your Active Directory. While the ILST securely syncs over member identities, including email addresses, profile information, and Group memberships, it never sends over passwords. Members added this way don't have Igloo passwords, and will need to either reset them using the password reset process, or more commonly, log in through single sign on. 

While many passwords are managed externally, it can be useful to ensure that a few Administrator accounts have native Igloo passwords. This will let them access Preview, authenticate with datafeeds, and access your digital workplace should there be an issue with the single sign on, like a certificate rollover. 

If you have other questions about passwords, the Igloo platform, workflows, or best practices, you can leave a comment here, or ask a question in the Community area.