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">
</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:
Configuration examples with popular 3rd party IdPs for FortiManager/FortiAnalyzer SP role:
