We are excited to announce the launch of native support for Identity Federation in NetApp BlueXP! This powerful new capability empowers administrators with a centralized, self-service experience to configure, test, and manage identity federations directly within the BlueXP console.
By integrating Identity Providers (IdPs) with BlueXP, enterprises, service providers, and partners can now enable their users to sign in to BlueXP using their corporate credentials, ensuring secure and streamlined access.
What Is Identity Federation?
Identity Federation delegates the user authentication to a trusted external party. To support this, we enable a federation admin to establish a trust relationship between BlueXP and their organization’s Identity Provider (IdP). This allows their IdP to authenticate users, while BlueXP controls authorization—determining what resources users can access.
Here’s how it works:
- An Enterprise user tries to access BlueXP by entering their email address.
- BlueXP redirects the user request to their enterprise IdP.
- The IdP authenticates the user and sends BlueXP a secure assertion or a claim containing the user’s identity and attributes.
- BlueXP uses this information to establish a session and determine the user’s access scope.
This model enables enterprises to maintain identity management through their own IdPs, while ensuring consistent and secure access control across BlueXP Data Services .
How It Was Done Before
Previously, federation setup and management were handled through a separate application — Cloud Central. This approach introduced several challenges:
- Disjointed admin experience, requiring users to switch between Cloud Central and BlueXP.
- Lack of visibility into federation health and workflows.
- Unable to federate domains other than the one used to login to cloud central
- Unable to switch federations from provider to the other provider
- Admins couldn’t manage user access as Cloud Central lacks role-based access controls
Why this Launch Matters
With native federation support now built into BlueXP, admins have the following benefits.
- Streamlined wizard experience: The new interface enables a BlueXP federation admin to go through a step-by-step process when configuring federation, allowing them to save progress at any point and seamlessly resume the setup later – ensuring flexibility and ease of use. Admins can now configure, test, manage, and troubleshoot federations entirely within the BlueXP console.
- Visibility: admins can view the federation workflows and health status.
- Domain Verification: With domain ownership verification built in, admins can prove they own the domain before configuring federation for that domain
- Support multiple domains: Admins can now configure multiple domains for a federation in a self-service fashion
- Switch federations between providers: BlueXP admins can now transition federation configurations between identity providers safely and seamlessly using a self-service workflow.
This launch significantly reduces service disruptions, minimizes support tickets, and enhances security and user experience—unlocking the full potential of identity federation for BlueXP customers.
Federation Setup
To setup federation, login to BlueXP with a Federation admin or with an Org admin role. Enter the Federation page under the IAM. We present the dashboard of the Federation service with metrics of the active federations and verified domains. This feature supports two main workflows.
They are as follows -
- Verify domain ownership
- Configure new Federation
Verify Domain Ownership –
If your login domain matches the Domain you are federating with then you don’t need to verify Domain Ownership. For e.g., If you are logged in as "user@example.com" but you plan to federate the domain “contoso.com”, in which case, BlueXP expects you to prove that you own the domain by adding the code BlueXP provides to your domain’s DNS TXT record.
This is typically achieved by sharing the code with your DNS server admin or with the Network admins at your work. Your admin will add the code as TXT record for the domain you planned to configure. Once this is complete, access the BlueXP Domain tab of the Federations, click the action “verify domain” and then issue Verify.
Configure new Federation -
Once you verify your domain ownership, BlueXP allows you to federate that domain. We have provided a wizard experience to configure federation in six simple steps as show below –
- Select the Domain
- Select a protocol or provider of your IdP
- Read Instructions to configure your IdP
- Create a federation connection
- Test the federation
- Enable the Federation
Step1 - Select one or more verified domain(s) you like to federate. If your login domain is the same as the domain you are federating, in which case you select the option of “your email domain”
Step2 - Select a protocol or the provider of your IdP. We support the following –
Protocols - SAML, OIDC and AD FS.
Providers - Entra ID, and Ping Federate.
Step3 – Instructions to configure your IdP
Step4 – Create Connection
- you need the following info for PingFederate - IdP Server URLs (sign-in and sign-out) and X509 signing certificate of the IdP
Step5 – Test the connection with your enterprise credentials
Upon clicking the test connection, a new page will be opened, the admin needs to enter their enterprise credentials. Upon successfully testing, click refresh page.
Step6 – Enable connection
Upon a successful test, you are allowed to enable the federation. If you miss this step, federation will not work for your domain.
Upon clicking Enable federation, you can notice that the federation is now enabled.
To prevent accidental deletions, we don’t allow deleting of the active federations. The admin has to set the federation to disable state and then delete the federation as a next step.
Switch Federations
Enterprise Identity admins have a business need to experiment with new Identity providers or protocols with a goal to safely transition between federations. The process is straightforward and secure. Here are the steps -
- First, configure and test a new federation for the same domain.
- Don’t enable it immediately.
- Disable the currently active federation
- Finally, enable the newly tested federation.
This approach ensures a smooth transition with minimal disruption, allowing admins to validate new configurations before making them active.
What’s next
- Receive proactive notifications when federation attributes (client-ID/client-secrets and certificates) are nearing expiration
- Deletion protection with confirmation prompts
