# SAML User Rights: Custom Attributes (Advanced) > These are the advanced way of setting up user rights. We recommend using [SAML Access Profiles](https://help.aikidogov.us/getting-started/automated-user-management/saml-login/saml-user-rights-access-profiles-recommended) > > [https://help.aikido.dev/doc/saml-user-rights-access-profiles-recommended/docVaVb0VPy1](https://help.aikidogov.us/getting-started/automated-user-management/saml-login/saml-user-rights-access-profiles-recommended) This guide provides detailed instructions on how to configure and manage user rights within Aikido using SAML custom attributes. By leveraging attributes such as `aikido_role`, `aikido_data_edit_rights`, `aikido_can_ignore`, `aikido_can_snooze`, `aikido_can_change_severity`, `aikido_can_manage_teams`, and `aikido_teams`, you can control user permissions and roles from within your identity provider. This approach ensures that users have the same access in Aikido as set up in your identity provider. * **aikido\_access\_profile:** [**More info**](https://help.aikidogov.us/getting-started/automated-user-management/saml-login/saml-user-rights-access-profiles-recommended)\ When setting up SAML Access Profiles, this is the claim to use. ```xml My Access Profile ``` * **aikido\_username:** You can define the name of the user in Aikido ```xml John Doe ``` * **aikido\_role:** `admin`, `default`, `team_only` ```xml default ``` * **aikido\_data\_edit\_rights:** `standard`, `read_only` ```xml standard ``` * **aikido\_can\_ignore:** `true`, `false` ```xml true ``` * **aikido\_can\_snooze:** `true`, `false` ```xml true ``` * **aikido\_can\_change\_severity:** `true`, `false` ```xml true ``` * **aikido\_can\_manage\_teams:** `true`, `false` ```xml true ``` * **aikido\_can\_export\_data:** `true`, `false` ```xml true ``` * **aikido\_can\_manage\_clouds:** `true`, `false` ```xml true ``` * **aikido\_can\_manage\_containers:** `true`, `false` ```xml true ``` * **aikido\_can\_manage\_domains:** `true`, `false` ```xml true ``` * **aikido\_can\_manage\_pentests:** `true`, `false` ```xml true ``` * **aikido\_can\_manage\_code\_quality:** `true`, `false` 
<saml:Attribute Name="aikido_can_manage_code_quality">
        <saml:AttributeValue xsi:type="xs:anyType">true</saml:AttributeValue>
    </saml:Attribute>
* **aikido\_can\_manage\_repos:** `true`, `false` 
<saml:Attribute Name="aikido_can_manage_repos">
        <saml:AttributeValue xsi:type="xs:anyType">true</saml:AttributeValue>
    </saml:Attribute>
* **aikido\_teams:** You can define the different teams where the user is a part of here. If the team(s) do not exist in Aikido, it will be created. The user will auto-join these given teams. The user will be removed from all other teams if this is set up. ```xml team1 team2 ``` * **aikido\_workspace\_ids:** You can define the different Aikido workspaces where the user is a part of here. The user will auto-join these given workspaces. The user will be removed from all other workspaces if this field is set up. ```xml 1233 2511 ``` * **github\_samlidentity\_nameid:** (GitHub.com) The NameID GitHub stores for that user, usually their email. Aikido uses it in two places: GitHub team sync, and linking a SAML user to the GitHub account that comments on a pull request so **Can ignore issues** applies. Team sync and this match only work when the person also signs in to GitHub with SAML. They must sign in to Aikido with SAML once after you add the claim. See [Who can ignore a finding on a pull request](https://help.aikidogov.us/pr-and-release-gating/aikido-ci-gating-functionality#who-can-ignore-a-finding-on-a-pull-request). ```xml example@email.com ``` * **github\_user\_slug:** (GitHub.com) The GitHub username, for example `johndoe`. Aikido matches it to the account that wrote a pull request comment, and uses it for GitHub team sync. When both this claim and `github_samlidentity_nameid` are stored, Aikido uses `github_user_slug` first. The person must sign in to Aikido with SAML once after you add the claim. ```xml johndoe ```