Technical Tip: SAML Attributes for ADOM and Admin Profile Override with Wildcard SSO Administrators

[iyotov]

Description

This article provides a reference about the SAML attributes, which can be used together with the options 'ext-auth-accprofile-override' and 'ext-auth-adom-override' for authorization of SAML SSO Administrators set to 'Match all users on remote serve'.

The solution below assumes that FortiManager/FortiAnalyzer is already correctly configured as a Service Provider (SP) and that the SAML SSO configuration is complete and working.

Scope

FortiManager 7.2.1 and up.

FortiAnalyzer 7.2.1 and up.

Solution

FortiManager/FortiAnalyzer in the SAML SP role can process the following attributes from the IdP:

<Attribute Name="username"> - Mandatory single-value attribute, which value must exactly match the NameID value of the assertion.

If a matching local/SSO administrator name is found on FortiManager/FortiAnalyzer side, the SAML user is assigned the permissions configured in that admin user object.

If no matching local/SSO administrator name is found on FortiManager/FortiAnalyzer side:

- If 'Auto Create Admin' is enabled, then the admin user is created and assigned the 'Default Admin Profile' specified in the FortiManager/FortiAnalyzer configuration.

- If 'Auto Create Admin' is disabled, then the login fails.

If a wildcard SSO administrator is matched:

- If multiple wildcard SSO admin objects exist on FortiManager/FortiAnalyzer, only the first one by CLI config order is matched.

- If 'ext-auth-accprofile-override' and 'ext-auth-adom-override' are disabled, then all SAML users, authenticated on the IdP side for this FortiManager/FortiAnalyzer SP, are assigned the admin profile and ADOM permissions, locally defined in the wildcard SSO admin object.

- If 'ext-auth-accprofile-override' and/or 'ext-auth-adom-override' are enabled, then the optional attributes below are used.

<Attribute Name="profilename"> - Optional single-value attribute, processed only if 'ext-auth-accprofile-override' is enabled.

If the value is matching existing admin profile name on FortiManager/FortiAnalyzer, then the user is assigned an admin profile as per the attribute value.

If the value is not matching the existing profile, then the user is assigned the admin profile defined in the wildcard SSO admin object.

If no 'profilename' attribute is sent, then the user is assigned the admin profile defined in the wildcard SSO admin object.

<Attribute Name="adoms"> - Optional multi-value attribute, processed only if 'ext-auth-adom-override' is enabled.

If the values contain matching ADOM names, then the SAML user is assigned ADOM access as per the attribute values.

If the values contain a mix of matching and invalid ADOM names, then the user is assigned the matching ADOMs and the invalid values are ignored.

If the values contain no matching ADOM names, then the user is assigned the ADOMs defined in the wildcard SSO admin object.

Below is a snippet from a SAML assertion, demonstrating the structure of the above attributes.

Other attributes, that the IdP might include in the statement, are ignored by FMG/FAZ:

...

  <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">ro.user@example.com</NameID>

...

    <AttributeStatement>

         ...

        <Attribute Name="username">

            <AttributeValue>ro.user@example.com</AttributeValue>

        </Attribute>

        <Attribute Name="profilename">

            <AttributeValue>Read_User</AttributeValue>

        </Attribute>

        <Attribute Name="adoms">

            <AttributeValue>ADOM2</AttributeValue>

            <AttributeValue>ADOM3</AttributeValue>

        </Attribute>

    </AttributeStatement>

...

Depending on the IdP and the tool used to capture the SAML assertion in the browser, the exact format may vary.

The important part is the names of the attributes, which should be configured on the IdP side.

With the attributes from the example above, 'ro.user' received the permissions defined in Admin Profile 'Read_User' and access to 'ADOM2' and 'ADOM3', although the 'adom' and 'profileid' settings of the matched wildcard admin object are different:

# config system admin user

edit "WILDCARD-SSO"

set user_type sso

set profileid "NO-ACCESS"

set adom-access specify

set adom "EMPTY"

set wildcard enable

set ext-auth-accprofile-override enable

set ext-auth-adom-override enable

next

end

If the IdP does not send valid 'profilename' and 'adoms' in the assertion, then 'ro.user' would receive profile 'NO-ACCESS' and access only to ADOM named 'EMPTY'.

Relate article:

Troubleshooting tips:SAML SSO Troubleshooting in FortiManager and FortiAnalyzer 

Configuration examples with popular 3rd party IdPs for FortiManager/FortiAnalyzer SP role:

SAML SSO Configuration with Azure AD 

SAML SSO Configuration with Okta
SAML SSO Configuration with Keycloak