Specify integration-specific user authentication for end-users to use their granted access
Apono offers two primary authentication methods for end-users who request and are granted access: Single Sign-On (SSO) and Apono-generated users.
These authentication methods allow organizations to choose the most suitable option for each resource, such as a cloud service, database, or SaaS application.
Not all integrations permit both types of authentication.
SSO leverages existing authentication mechanisms, allowing users to log in to a resource using their credentials from a centralized identity provider.
When SSO is selected, Apono redirects users to the appropriate SSO portal for authentication, integrating seamlessly with the organization's existing user directory.
This option is often used in the following use cases:
Cloud services
SaaS products
Organizations with existing identity providers
The common pros and cons of using SSO are listed in the following table.
For integrations that support SSO, you can choose the integration-specific SSO option (such as IAM Auth) in the Integration Config section under Auth Type. Our documentation for the specific integration identifies the SSO option.
Apono creates and manages user accounts directly within the target system.
When the Apono-generated user option is selected, Apono generates usernames (typically in the format username_apono
) and strong, random passwords.
This option is often used in the following use cases:
Databases
Systems without native SSO support
The common pros and cons of allowing Apono to generate users are listed in the following table.
For integrations that support non-SSO credentials, you can choose the integration-specific Username/Password option in the Integration Config section under Auth Type. Our documentation for the specific integration identifies this option.
Pros | Cons |
---|---|
Pros | Cons |
---|---|
Centralizes user management
Integrates with existing security infrastructure
In some instances, supports multi-factor authentication (MFA)
Can require additional service costs
Requires an existing SSO infrastructure
No additional SSO infrastructure required
Enables managing user clean up and password rotation
Prevents centrally managing Apono-generated users with other organizational account
May encounter account quota limits within individual systems