Does Honeycode support IAM Identity Center?
Yes, Honeycode currently supports IAM Identity Center (successor to AWS Single Sign-On (SSO)) in us-west-2 (Oregon) on our paid Pro and Plus plans. Currently supported identity providers (IdP) include Microsoft Active Directory, Azure AD, Okta, One Login, PingFederate, or any SAML-based IdP, including Google Workspace (formerly known as G Suite). For further details on setting up IAM Indentity Center, please see our Honeycode Admin Guide on AWS Documentation.
Decision Matrix: Amazon Honeycode Standard Teams vs. IAM Identity Center Teams
Use this matrix to decide whether Standard Teams or IAM Identity Center Teams is the better fit for your organization.
| Standard Teams | IAM Identity Center Teams | |
|---|---|---|
| Does your organization use SSO currently? | Not recommended | Recommended to ensure Honeycode works like other SSO enabled applications |
| Organizational mandate for IAM Identity Center | Not recommended | Recommended to meet corporate mandates for access control and access management |
| Pricing tiers | Basic, Plus, and Pro tiers | Plus and Pro pricing tiers only |
| Team size | Admins manually invite and remove users. Consider if this is practical in the event your team size scales up or down. | IT team can easily manage members via a central identity management system as your team size scales up or down. |
| Prerequisites | Email address | AWS Organizations and AWS IAM Identity Center setup in US-WEST-2 (instructions below) |
| Can invite users from outside of your organization? | Yes | No |
| Can share with pre-existing groups from your identity provider (IdP)? | No | Yes |
| Security | Data stored in US data centers; can be accessed worldwide. Usable on both web and mobile platforms. Data is always encrypted (i.e., at rest and in transit) | Data stored in US data centers; can be accessed worldwide. Usable on both web and mobile platforms. Data is always encrypted (i.e., at rest and in transit) |
| Supports multiple email domains | Yes. Can invite users from any domain (e.g., example.com, gmail.com, yahoo.com, etc.) | Yes. Users from corporate domains you control and can verify with DNS records (e.g., example1.com, example2.com, but not gmail.com) |
| Team management and invitations | Honeycode Team Admins can choose who can be invited and can delegate invitation to some members (see article) | You cannot invite via Honeycode. The group that manages your corporate credentials, Identity Provider (IDP), and Single Sign On systems can add and delete members |
| Sharing | Can share with any user on the team | Can share with any user or groups managed by your identity provider |
| Notifications | Can send notifications to any user in the team | Can send notifications to any user or group managed from your identity provider |
| Region dependency | Runs and stores data in US-WEST-2 | Runs and stores data in US-WEST-2; needs AWS IAM Identity Center setup in US-WEST-2 |
| Supports subdomains | Not relevant, a subdomain is like another email address from another domain | Yes, but each subdomain must be validated as if it was an additional domain you own |
IAM Identity Center Best Practices in Honeycode
Introduction
This document describes IAM Identity Center teams and provides best practices and key considerations for those evaluating implementing them.
Teams overview
While they function somewhat like groups, teams in Honeycode are more like independent containers of tools for specific organizations. Teams are important because they are containers for the workbooks (and apps) you develop. Workbooks, user sharing or migration between teams is not supported. Access and sharing are limited to members of the team where the workbook resides and, you can only see workbooks the teams where you are a member. Teams are also the payment unit in Honeycode; therefore, you pay at the team level for all the users in a team – based on the pricing tier of the team. Any security, sharing, and cost conversation will involve a discussion about teams.
Standard vs. IAM Identity Center teams overview
Amazon Honeycode supports two kinds of teams: Standard teams and IAM Identity Center teams. In this document we will provide best practices for setting up and working with IAM Identity Center teams. For definitions see Honeycode Glossary of terms, plus we provide a short comparison of Standard and IAM Identity Center teams in the decision matrix.
But first, a quick word about Standard teams. Honeycode automatically creates a Standard team when you sign up for an account using your email address. This is your own team where you are an administrator and invite other users. Standard teams allow you to invite people using any email address regardless of email domain (same domain, different domain, yahoo, gmail, corporate domain, subdomain, etc.). However, people with email domains associated with an IAM Identity Center team cannot join a Standard team. To understand if Standard teams or IAM Identity Center teams are best for you please see our decision matrix.
If your organization requires that you use a central identity provider (IdP), consider creating IAM Identity Center teams. IAM Identity Center teams allow users to log into Honeycode with the same credentials they use for desktop login or other corporate applications. After you setup an IAM Identity Center team within Honeycode, the IT administrators can control which groups of users get access to Honeycode.
Amazon Honeycode supports single sign-on via AWS IAM Identity Center. Honeycode IAM Identity Center teams support any IdP providers that AWS IAM Identity Center fully supports: Okta, Azure AD, OneLogin, PingFederate, and some that AWS IAM Identity Center supports partially/differently: [Google Workspace (formerly G-Suite)](https://aws.amazon.com/blogs/security/how-to-use-g-suite-as-external-identity-provider-aws-IAM Identity Center/) does not support SCIM, self-managed Active Directory via AD Connector. See the sections below for general recommendations, or those specific to your IdP.
This document provides some tips to help you setup and operate an IAM Identity Center team, it does not obsolete, recommend or replace any of your security procedures and policies, or any best practices provided by AWS IAM Identity Center or AWS Security teams. Security in the cloud is your responsibility.
IAM Identity Center Teams Concepts and Best Practices
Choosing AWS IAM Identity Center and AWS Organizations Location
Depending on how you have setup IAM Identity Center you might need to make some changes based on the regional limitations of IAM Identity Center and Honeycode’s need to have IAM Identity Center in US-WEST-2. Here is the context you need to know, and the two options you have available for setting up IAM Identity Center with Honeycode.
Amazon Honeycode requires IAM Identity Center to be setup in US-WEST-2 region. If you already have IAM Identity Center set up outside of US-WEST-2, then you need to create a new AWS Account with a new AWS Organization and set up IAM Identity Center, in that account, in US-WEST-2.
Here are the recommended options. Both of these options will work with your preferred IdP if supported by IAM Identity Center (see links above), and they have to do more with the choices your company makes about where, within AWS, to host administrative infrastructure such as IAM Identity Center, LDAP and so on.
Option 1: New or Existing IAM Identity Center in US-WEST-2
If you do not have AWS Organizations and IAM Identity Center setup anywhere else in the AWS Cloud, and you don’t have any IT requirements to set IAM Identity Center in other regions, consider setting up IAM Identity Center in US-WEST-2.
Having IAM Identity Center in US-WEST-2 will work with Honeycode immediately and will support other applications and future cloud adoption. If you are setting up AWS Organizations and IAM Identity Center for the first time, consider using the AWS Landing Zone pattern for most flexibility and future proofing your cloud infrastructure. US-WEST-2 will become the home of your IAM Identity Center implementation (one per organization), and future IdP integrations will be done with this IAM Identity Center instance.
To avoid clashing with other cloud applications and operations you have, we recommend creating a separate AWS Account in your organization for use with Honeycode teams and workloads – using IAM Identity Center teams. Honeycode billing will be associated with this account, and charges will show up in your Cost and Usage Report (CUR) in your Main account. In this account you also run the integrations (AppFlow and Lambda), and set cross account replication and roles to move data in and out of this account.
See other IAM Identity Center documentation here, and any recommendations for Honeycode and IAM Identity Center here.
- Honeycode works with any IdP supported by IAM Identity Center, ** Accounts recommended by AWS Landing Zone*
### Option 2: Parallel IAM Identity Center for Honeycode in US-WEST-2
If your organization already has IAM Identity Center in another region (e.g., US-EAST-1), create a separate AWS Account, setup another AWS Organization, and IAM Identity Center in US-WEST-2 specifically for Honeycode; in parallel to your existing setup for other services.
This new AWS Account, AWS Organization and IAM Identity Center will not be linked with your main or existing infrastructure; except that you can link the new IAM Identity Center as another application in your IdP and therefore share the same users between your two parallel IAM Identity Center and Organizations setup. You still manage users in one central IdP, but you will have two IAM Identity Center instances syncing users down from your IdP. For this new AWS Account (Honeycode Prod. Acct.), setup a separate payment method, because this account cannot be linked to your AWS Cloud (Main) Acct – this is a limitation of AWS Organizations.
We assume that your existing/main IAM Identity Center setup is implemented according to all the best practices mentioned in Option 1 above. For this separate and standalone account, your AWS Organization, IAM Identity Center and Amazon Honeycode can all be in one AWS account. In this case, you will be using IAM Identity Center and Organizations only for Honeycode, and will therefore avoid creating and managing an excessive number of AWS Accounts.
Honeycode works with any IdP supported by IAM Identity Center, ** Accounts recommended by AWS Landing Zone*
## Key concepts for IAM Identity Center teams
### IAM Identity Center team is a new container
When setting up an IAM Identity Center team you are creating an empty container for your workbooks and applications. You need to synchronize users from your IdP via IAM Identity Center, and create workbooks and apps from scratch. Before you decide on a new IAM Identity Center team we recommend planning the migration (see below) to ensure least amount of down time.
### IAM Identity Center teams claim an entire domain
When setting up an IAM Identity Center team you need to verify ownership of your domain (e.g. example.com). Once your domain is verified and the IAM Identity Center team is created all login attempts with email addresses @example.com will be directed to the new IAM Identity Center team, and any Standard teams, created with @example.com domain, will be inaccessible. The workbooks, apps, and data in the Standard teams will not be deleted, however, you will not be able to reach them. Three tips will help here:
Invite one or more users from a different email domain (e.g., @dev.example.com, or @gmail.com) to your Standard team before you verify your domain with the new Honeycode IAM Identity Center team. These users will still have access to the Standard teams because they will be coming from another domain, not linked with Honeycode. Be sure to share, as Owner (not Collaborator), the necessary workbooks with these users. A user can only see the workbooks and apps they have created, or have been shared with them.
- Make sure you have at least one user, from the different domain, as Admin in the Standard team. This user may need to invite new users.
- See Migration to IAM Identity Center teams section below to understand what is possible and how to get help.
An IAM Identity Center team can have multiple domains verified and directed to it. However, you need to own those domains and/or be able to add TXT records to their DNS zone file. Subdomains are treated as separate domains and you will need to put DNS records in the zone file for the subdomains as well to verify ownership. See DNS setup instructions for details.
IdP groups for IAM Identity Center teams
The power of IdPs comes in part from the ability to manage groups of users. Honeycode requires your IdP to provide two types of groups of users - one for team administrators and one for team members. From the groups synchronized to IAM Identity Center you can select any and assign them as admins or member groups. These two types groups sync to IAM Identity Center and will be available to Honeycode where they will constitute the administrators and member user pools within the Honeycode team. The members groups are optional.
Team members can create and share workbooks, use applications shared with them just like Admins. How many Admins you have depends on your specific team and use case, but we recommend keeping the number of admins low in proportion to the number of team members.
When designing the groups for Honeycode use please consider the following. IAM Identity Center teams depend on IAM Identity Center and the limits for that service. You might also want to consider Honeycode’s per user pricing and create separate groups only for the users who should have access to Honeycode. You might not want to sync the entire Finance, Facilities, HR, and Support groups to Honeycode; instead, you might want to create a HC-Users and HC-Admins group in your IdP and use those in Honeycode.
To isolate teams or departments and prevent inadvertent sharing of workbooks and apps with sensitive data, you might want to create multiple Honeycode IAM Identity Center teams, one for each department. You can create multiple Admin and Member teams – a pair for each department. For example, when creating two IAM Identity Center teams, one for Finance and one for HR you would create Honeycode-Finance-Admin and Honeycode-Finance-Members as well as Honeycode-HR-Admin and Honeycode-HR-Members groups in your IdP. In IdP you would assign the appropriate users to the correct groups. A user can be in multiple IdP groups.
Uniqueness of email addresses
Changing a user’s email in your IdP (daniel@example.com to dan@example.com) can lock users out of Honeycode and workbooks owned exclusively by that user might be deleted. Just like other login problems, these changes can cause login problems with IAM Identity Center and Honeycode. We recommend referring to the default mappings that IAM Identity Center does and avoid making changes without announcing them and planning a migration. Some common and minor issues can be resolved with little incidence, while others require more complex planning.
How you configure the attribute mappings between your IdP and IAM Identity Center can affect user’s ability to log in after email address changes. Honeycode uses the “email” attribute from IAM Identity Center to identify unique users. Please check your IdP to IAM Identity Center mappings to ensure they meet your needs - see AD mappings.
Here are different scenarios:
| Action in IdP | IAM Identity Center Teams Implication | Solution |
|---|---|---|
| Add user to group linked with IAM Identity Center (and Honeycode Team) Note: the group may not necessarily be linked with a “Team” | Creates new user in IAM Identity Center and user is added to Honeycode team | N/A |
| Remove user from group linked with IAM Identity Center (and Honeycode Team) Note: the group may not necessarily be linked with a “Team” | Removes user from IAM Identity Center and Honeycode; workbooks owned exclusively by this user will be deleted | Add multiple Owners to a workbook so it does not get deleted |
| Disable user | Disabled user has the same impact as a deleted/removed user | Re-enable user in IdP and user will have access to all previous workbooks |
| Change a user’s email address | New user is created in IAM Identity Center and in Honeycode; user cannot access previous workbooks and apps | Will need to re-share apps and workbooks with new user; add a group as an owner of the workbook |
| Add vanity email or aliases | You cannot log in using vanity emails or aliases | Check IAM Identity Center attribute mappings for more details |
Automated Sync of Users (SCIM)
Setup the System for Cross-domain Identity Management (SCIM) to automatically update IAM Identity Center with the users in your IdP groups, otherwise you lose most of the benefit of implementing IAM Identity Center – the auto provisioning and de-provisioning of users. See the IAM Identity Center for more information for SCIM.
Migration to IAM Identity Center teams
Currently users cannot migrate Honeycode workbooks or users from one Honeycode team to another. Workbooks and apps need to be re-created in the new team that you set up. Lambda or other integration code can be moved via GIT to any AWS Account. Data can be re-imported into Honeycode from external sources, via the APIs, after re-creating the workbooks and apps in the new teams. This is true for of any teams, IAM Identity Center or Standard. Specifically, creating an IAM Identity Center team does not move users from the Standard to IAM Identity Center teams either. Instead, the IAM Identity Center process provisions users into the new IAM Identity Center team. This means you need to re-share the apps once they are re-created and users provisioned in the new IAM Identity Center teams.
For further help and best practices on moving from Standard teams to IAM Identity Center teams, please contact our customer engagement team: honeycode-ce@amazon.com.
Specific IdP Tips
We will continue to add IdP specific tips for the different IdPs we support. In general, however, follow the IAM Identity Center documentation for integrating your IdP with Honeycode. Honeycode uses IAM Identity Center to integrate with various third party IdPs (see discussion of supported IdPs above).
Working with Azure Directory
When setting up IAM Identity Center as a service in Azure Active Directory (under Enterprise Applications) please make sure to use “AWS Single Sign-on” not “AWS Single-Account Access.”
Working with Google Workspace
Google workspaces supports System for Cross-Identity Management (SCIM) for users, but not for groups. You may need to manually update changes to group memberships in IAM Identity Center. To manually sync users you can setup this SSOSYNC from GitHub – start here.
NOTE: Honeycode primarily works with groups and determines the users based on the group memberships. Thus, syncing just the users would not reflect the changes into Honeycode, unless the group memberships are also updated.
If you need help
For IAM Identity Center documentation start on the documentation website or the Honeycode forum:
Ask for specific help on the Honeycode community forum. If you have an AWS Account, open a case in the AWS Support Console.
| Was this article helpful? |
|---|
- Yes
- No
0 voters