The example here walks through an Oxide IdP setup using Cisco Duo’s SAML 2.0 service. The Duo Core Authentication Service version referenced in this guide is D303.11. Some of the UI elements may differ in the version you are using but the setup instructions should remain applicable.
The steps below assume that you have already followed Duo’s documentation to configure an authentication source as the SAML identity provider, ready to be used for cloud application single sign on.
Create Duo cloud application
To begin the setup, navigate to Applications on the left navigation bar and click Protect an application.
You’ll be asked to choose an application. Search for "Generic SAML Service Provider" and click Protect.
Get metadata
A set of application SSO data is generated for your new application. The key information you’ll need from here is the Entity ID and Metadata URL (or XML file). When you set up the identity provider on Oxide, you’ll enter either the URL (if Oxide upstream network allows internet access), or import the XML file directly.
Enter service provider details
Under Service Provider, there is another Entity ID. This should be a unique name that can be easily associated with the silo you are about to create. In this example, we’ll use the silo name for simplicity.
Enter the Oxide login endpoint as the ACS URL which follows this naming convention:
https://$siloName.sys.$oxideDomainName/login/$siloName/saml/$providerName
In this example, we’ll name the silo testduo and the provider duo in an Oxide rack running on the subdomain rack2.eng.oxide.computer. The URL in this case is
https://testduo.sys.rack2.eng.oxide.computer/login/testduo/saml/duo
Enter the same URL for Single Logout URL and Serivce Provider Login URL.
SAML Response
Except for Role attributes, you can leave the SAML Response settings to their default values.
Role attributes are used for passing authorization information to Oxide. The attributes will become Oxide groups that get mapped to built-in roles. Here, we name the attribute key "groups" but it can be named differently according to your organization’s policy or naming convention. The example shown above provides two types of access for the Oxide "testduo" silo - admin and user. The former group will be configured to have the silo admin role and manage all access policies within the silo. The latter group will have its access configured by an admin.
When a user has successfully logged into the "testduo" silo, the user account and associated groups are imported into Oxide. The level of access granted to the user will depend on their group memberships and the mappings for each of the groups.
Other application settings
Further down in the Settings section, update the application Name to a unique name. You may leave all other settings to their default values.
Create Oxide silo and identity provider
Now we are ready to create the new silo using Duo for authentication and authorization. Navigate to the System menu using the dropdown at the top right-hand corner of the web console (next to user name).
Create silo
First, select Silos and create a new silo.
The silo name must match with what you used in the Duo application ACS URL. The Admin group name is the one you will be setting or already set earlier in the role attributes of users who are granted the silo admin role. The silo admin user(s), once logged in and imported into Oxide, will have the necessary permissions to manage the roles of other users onboarded later on.
The Role mapping options provide silo admins and/or viewers the access to fleet-level system information. You’ll likely grant the additional access only to silos used by operators and power users. This will eliminate the need for anyone requiring fleet-level access to log in as the built-in recovery user.
Before clicking Create Silo, ensure you have added a TLS certificate with a matching common name.
Create identity provider
The provider setup requires a number of data input which should all be available from Duo. The screen shots below illustrate the input that corresponds to the "testduo" Duo application settings:
Here we use "duo" as the provider name to let users know which system they are authenticating with. It can be named differently according to your organization’s policy or naming convention.
The Service provider client ID should correspond to the Entity ID you specified under the Duo application Service Provider section.
The ACS URL is generated for you based on the silo and provider names following the naming convention:
https://$siloName.sys.$oxideDomainName/login/$siloName/saml/$providerName
Assuming that Oxide is running on the subdomain rack2.eng.oxide.computer, the URL rendered in the UI will be
https://testduo.sys.rack2.eng.oxide.computer/login/testduo/saml/duo
The Entity ID should be the URI generated by Duo (under the Metadata section).
The Group attribute name should be set to the Duo Role attribute name.
You may set the Metadata source to XML and import the metadata.xml file downloaded from Duo earlier, or choose the URL option and enter the URL if the rack upstream network has internet access.
Log in as a Duo user
If everything is configured correctly, you should be able to log in as the users set up in Duo.
Clicking SIGN IN should redirect you to the login page of the authentication source configured in Duo.
admin) doesn’t match with the Admin group name in the silo. You can view which groups the user has been imported with by navigating to the profile page https://$ACS_URL_ROOT/settings/profile.User roles and groups
The role attributes defined in Duo are used to create silo groups and assign memberships. Users should see the same groups as the ones mapped in the Duo application Role attributes section.
The role specified as the silo’s Admin group name should be reflected on the Access tab.
