The platform supports SAML 2.0 for Single Sign-On (SSO) and SCIM 2.0 for automatic user and team provisioning. Work with your Customer Success Manager to verify your SSO configuration before starting the training program.

This guide covers the following platform configuration areas:

• SAML Single Sign-On (SSO)
• SCIM 2.0 provisioning

SAML Single Sign-On (SSO)

1. Go to the Management Interface. Under Manage, select Organizations on the left navigation panel, then click Details.
   
2. Scroll to the Single Sign-On & User Provisioning section, then click Setup SAML SSO, and  modal window will pop-up.
   
3. Use the modal window to configure SSO.
   • Download the platform's Service Provider (SP) metadata file and install it on your identity management platform.
   • After you install the application, download the Identity Provider (IdP) metadata file from your identity management platform. Click Choose file, select the IdP metadata XML file, then click Upload IDP Metadata.
   • Wait a few seconds for the configuration fields to populate automatically.
   • Click Save to save the SSO settings.
   

   
   

   Note: This configuration does not affect users who use password based authentication.

4. Test SSO authentication with a single user before enabling it for all users.
   • Enable SSO for one user so you can verify that authentication works correctly.
   • Select Users from the left navigation panel. Click Details for the user you want to test, then click Edit in the top right of the user's profile page.
   • In the modal window, set Single Sign-On to Enabled.
   • Click Update User.
   

   Inform the user that you updated their profile and ask them to log in to the platform. The platform redirects the user to the SSO authentication page. After successful SSO authentication, the user can access the platform.

5. After you verify SSO, return to the organization Details page. In the Single Sign-On & User Provisioning section, click Enable for all users to enable SSO for all users.
   

SCIM 2.0 Provisioning

The platform supports SCIM 2.0 for automatic provisioning and deprovisioning of users and teams. Work with your Customer Success Manager to verify the SSO integration before configuring SCIM.

IMPORTANT:
Test the SCIM integration before deploying it to all accounts.

Create a small test group containing one or two accounts and provision only those accounts first. After your Customer Success Manager confirms that the integration works correctly, proceed with onboarding the remaining users.

If you are the integration engineer, request email confirmation from a Customer Success engineer before you provision a test group or begin onboarding users for the first time. Contact success@secureflag.com.

Provisioning a large group before the planned onboarding date may cause every account in that group to receive an invitation email early, which can affect the program.

1. Before you configure SCIM 2.0 provisioning for your organization, make sure you have enabled Single Sign-On.
2. Click Generate to generate a SCIM token. The token appears in a modal window. Save the token securely because you cannot view it again after you close the window. If you lose the token, generate a new one.
3. Set the SCIM Provisioning control to Enabled to start provisioning users through SCIM.
4. Add the SCIM token to your identity management platform.
   

User Deactivation and Deletion Process

When you remove a user from a group or application assignment in your identity management platform, such as Okta or Azure, the identity management platform automatically marks that user as inactive on the platform.

This is the default behaviour of the identity management system and cannot be modified or customised. Inactive users continue to count toward your active licence quota, and their data remains stored until you delete the users manually.

To permanently remove inactive users, follow the relevant Platform-specific SSO and SCIM guides below.

SAML and SCIM with multiple subscriptions

If your organization has more than one subscription, you can use the custom attribute sf_subscriptionId to control which subscription a user belongs to. The attribute is supported by both SAML and SCIM.

SAML: Send sf_subscriptionId as a claim in the SAML assertion. When a new user signs in for the first time, just-in-time (JIT) provisioning creates the user directly in the specified subscription. For existing users, the claim is evaluated at each sign-in, so you can use it to set or change the user's subscription.

SCIM: Send sf_subscriptionId as part of the user record during provisioning. The user is created in, or updated to, the specified subscription.If your Organization has more than one subscription, you can control which subscription a user is added to by setting the custom attribute sf_subscriptionId.

Find your subscription Ids

Go to Organizations → Details → Account & Subscriptions. Each subscription is listed with its ID.

Set the attribute in your Identity Provider

Add sf_subscriptionId as a custom attribute in your identity provider and set each user's value to the ID of the subscription they should belong to. See the guide for your identity provider for the exact steps in the section below. If the attribute is not sent, the user is added to your default subscription.

Custom Attributes 

SecureFlag supports parsing custom attributes for SAML and SCIM to configure user access, including role, team, managers, tags, and ThreatCanvas project permissions.

Important Considerations:

• Custom claims are applied only if the custom "Custom SAML Claims" toggle is enabled on the target organization. 
• When enabled, any attribute returned in the SAML assertion overrides the existing user values (including those set via the Web Management interface).

This is a list of all the custom attributes supported by the SecureFlag platform. Instructions on setup can be found in the Platform-Specific SSO and SCIM guides below.

Subscription Selector (SAML and SCIM)

Specifies which subscription to create the user in when the same Organization has multiple subscriptions that share the same SAML configuration. If omitted, the default subscription is used.

Organization Selector (SAML only)

Specifies which organization to create the user in when multiple Organizations share the same SAML configuration. If omitted, the first matching organization is used.

Role (SAML and SCIM)

Defines the user’s role on the SecureFlag platform.

The following roles are available:

Tip: Assign the role with the least privilege necessary. Setting sf_role also controls eligibility for sf_managed_teams (only valid for Team Manager and Organization Admin roles).

Team Membership (SAML only)

Assigns the user to a team.

Managed Teams (SAML only)

Grants the user manager permissions over specific teams. Only applied if the user’s role is Team Manager or Organization Admin.

Manager (SAML only)

Specifies the email address of the user’s manager.

Tags (SAML only)

Adds a list of tags to the user.

ThreatCanvas Projects (SAML only)

Defines project permissions for ThreatCanvas.

Permission Values:

• RO = Read Only
• RW = Read/Write

Example SAML Assertion

<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
  <saml2:Issuer>https://idp.example.com/12345</saml2:Issuer>
  <saml2:Subject>
    <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
      jane.doe@example.com
    </saml2:NameID>
  </saml2:Subject>
  <!-- First name -->
  <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
    <saml2:AttributeValue>Jane</saml2:AttributeValue>
  </saml2:Attribute>
  <!-- Last name -->
  <saml2:Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
    <saml2:AttributeValue>Doe</saml2:AttributeValue>
  </saml2:Attribute>
  <!-- Organization selector -->
  <saml2:Attribute Name="sf_org">
    <saml2:AttributeValue>42</saml2:AttributeValue>
  </saml2:Attribute>
  <!-- Subscription selector -->
  <saml2:Attribute Name="sf_subscriptionId">
    <saml2:AttributeValue>176</saml2:AttributeValue>
  </saml2:Attribute>
  <!-- Role -->
  <saml2:Attribute Name="sf_role">
    <saml2:AttributeValue>3</saml2:AttributeValue>
  </saml2:Attribute>
  <!-- Team Membership -->
  <saml2:Attribute Name="sf_team">
    <saml2:AttributeValue>Blue Team</saml2:AttributeValue>
  </saml2:Attribute>
  <!-- Managed Teams -->
  <saml2:Attribute Name="sf_managed_teams">
    <saml2:AttributeValue>Blue Team,Red Team</saml2:AttributeValue>
  </saml2:Attribute>
  <!-- Manager -->
  <saml2:Attribute Name="sf_manager">
    <saml2:AttributeValue>lead.manager@example.com</saml2:AttributeValue>
  </saml2:Attribute>
  <!-- Tags -->
  <saml2:Attribute Name="sf_tags">
    <saml2:AttributeValue>Security,EMEA,Contractor</saml2:AttributeValue>
  </saml2:Attribute>
  <!-- ThreatCanvas Projects -->
  <saml2:Attribute Name="sf_projects">
    <saml2:AttributeValue>{ "Project Alpha": "RW", "Project Beta": "RO" }</saml2:AttributeValue>
  </saml2:Attribute>
</saml2:Assertion>

Just-in-Time (JIT) User Provisioning

With JIT provisioning enabled, a user can automatically create an account in SecureFlag upon their first successful authentication. SecureFlag redirects the user to the organization’s Identity Provider (IdP), and after validating both the authentication and the user’s access rights, creates the account.

Note: Advanced User provisioning and lifecycle management can also be handled via SCIM. 

JIT Provisioning Use Cases:

• SCIM is not available.
• The organization would like to grant access to all users but only create an account on SecureFlag the first the time the user authenticates.

To Enable JIT Provisioning:

• Go to the Organizations page.
• Click Details for your organization.
• In the Single Sign-On & User Provisioning panel, enable the JIT toggle.
  

Authorization Note: Ensure that users are assigned to the SecureFlag application in your IdP. Assignment can be done either directly to individual users or through group membership.

SAML JIT  IdP-Initiated Flow

• The user clicks the SecureFlag tile in their IdP dashboard.
• SecureFlag reads the SAML Issuer and matches it to one or more organizations associated with that IdP.
• When a valid SAML assertion is received, SecureFlag creates the account. The NameID attribute is used as the username/email.

Configuration Scenarios:

• Single Organization with a single Subscription → no additional configuration need.
• Single Organization with a multiple Subscriptions → include the sf_subscriptionId attribute in the SAML claims to select the Organization. If not provided, the default subscription for the Organization is selected.
• Multiple Organizations bound to the same Issuer → include the sf_org attribute in the SAML claims to select the target Organization
• Multiple Organizations with different SAML configurations → no additional configuration needed.

SAML JIT SP-Initiated Flow

• The user visits the SecureFlag login page and enters their email.
• SecureFlag matches the domain portion of the email against the main contact domain for the Organization, or the list of allowed SSO domains for the Organization (both can only be set by Customer Success).
• When a valid SAML assertion is received, SecureFlag creates the account. The NameID attribute is used as the username/email.

Configuration Scenarios:

• Single Organization with a single Subscription → no extra configuration.
• Single Organization with a multiple Subscriptions → include the sf_subscriptionId attribute in the SAML claims to select the Organization. If not provided, the default subscription for the Organization is selected.
• Multiple Organizations with different, non-overlapping email domains → no extra configuration.
• Multiple Organizations with overlapping email domains:
  • If the Organizations use the same SAML configuration → include the sf_org attribute in the SAML claims to select the Organization.
  • If the Organizations use different SAML configuration → only one Organization can have JIT enabled; if multiple are enabled, the first is selected by default.

SAML JIT Provisioning Required Attributes

SAML assertions must include first name and last name. SecureFlag recognizes several attribute names (case-insensitive):

Platform-Specific SSO and SCIM Guides

Single sign-on (SSO) and user provisioning are supported through SAML 2.0 and SCIM 2.0. The sections below include configuration steps for Microsoft Entra ID (formerly Azure AD), Okta, and OneLogin. To adapt these steps to your specific deployment, consult your identity provider's (IdP) documentation or administrator.

Azure

Okta

OneLogin

Azure

Azure / Entra ID

When enabling Single Sign-On (SSO), work with your organization’s Identity & Access Management engineer to ensure a smooth onboarding process before commencing the training program. This guide provides instructions for setting up Single Sign-On on Azure via SAML using the Create your own application functionality.

Supported features

• SP-initiated SSO
• IDP-initiated SSO
• SCIM (documentation available in a separate document)

Requirements

1. The Azure Single Sign-On integration is only available for the Enterprise and Business plans.
2. Users will need to be set up on the SecureFlag platform. Make sure that the users’ emails exactly match their Azure accounts.
3. Complete the steps below to set everything up.

Note: If setting up multiple SecureFlag applications, speak with your Customer Success Manager; this requires an additional step.

Configuration Steps

1. Go to https://portal.azure.com/ , and navigate to the Microsoft Entra ID menu, then to Enterprise Applications.
   
2. Click on New Application.
   
3. Select Create your own application.
   
4. Fill in the user-facing app name, then click add.
   
5. The app is now created. You can optionally set a logo: click on Properties, and upload a SecureFlag logo (you can download it here). Then click on Save.
   
6. Click Configure single sign-on and select SAML.
   
7. Click Upload Metadata File. Select the Service Provider metadata that was obtained from the SecureFlag platform (Click here for instructions on how to get the Metadata file).
   
8. The configuration details will be automatically imported. Click on Save.
   
9. When configuring the SAML claims, use the user email as the Name identifier format. The user email will likely be configured under user.mail although Windows based organizations may have this configured under user.userprincipalname. Confirm this with your Identity & Access Management Engineer.
   
10. Download the ‘Federation Metadata XML’ to upload to the SecureFlag platform (Click here for instructions on how to upload the Federation Metadata file).
    
11. You need to assign users to the newly created and configured application.
    
    This can be done on an individual level, or with groups. By default when a group is configured on Azure, this will populate in SecureFlag as a Team.
    
    If you do not want to manage teams in SecureFlag via Azure Groups, you can disable this behavior by adjusting theAttribute mappings. In the attribute mapping settings, set this to No.

Complete the configuration on the SecureFlag platform.

Once you have the required Federation Metadata XML file from Azure, nefer to this article to set it up on the SecureFlag platform. For additional support please contact support at: https://www.secureflag.com/support.html

SCIM 2.0

SecureFlag supports the SCIM 2.0 protocol for auto-provisioning and deprovisioning users and teams. Before implementing the SCIM configuration, work with your CSM to ensure the SSO integration's correctness. 

Supported features

• Create users
• Update user attributes
• Deactivate users
• Group push

Requirements

1. Users will need to be set up on the SecureFlag platform. Make sure that the users’ emails match those of their Azure accounts.
2. Complete the steps below to configure SCIM.

IMPORTANT

SCIM integration must be tested before deployment to all accounts.

To test, create a small group of 1-2 accounts to be provisioned to SecureFlag. Once your Customer Success Manager confirms the integration, you may proceed to onboard the rest of the users.

If you are the Identity & Access Managmeent engineer, request an email confirmation from a SecureFlag customer success engineer before pushing a group for testing or onboarding for the first time. You can reach them at success@secureflag.com.

Pushing to a large group of users may result in all accounts within the group receiving an email invite before the onboarding date, which will affect the program.

Configuration Steps

1. Go to https://portal.azure.com/, and navigate to Microsoft Entra ID in the menu to your left, then on Enterprise Applications.
   
2. Browse to the SecureFlag application. Click on Provisioning, then click on Get Started.
   
3. Enter the SCIM endpoint URL https://api.secureflag.com/rest/scim/v2 and the Secret Token (see this article to get token).
   
   Click Test Connection to verify the correct setup.
   

Note: When a user is deactivated on Azure, the user's status is set to "Inactive" on SecureFlag. An inactive user still counts against the total number of active licenses, and their data is retained in the platform. To delete users, set up a workflow in Azure to issue a request to the SCIM's DELETE endpoint.

User Deactivation and Deletion Process

When a user is removed from a group or app assignment, Azure marks them as “Inactive” in SecureFlag. If a user is deleted from the Directory, Azure first marks them as “Inactive” in SecureFlag and, after 30 days, automatically sends a delete request to remove them permanently. This is standard Azure behavior and cannot be customized or configured. Inactive users still count against your active license quota, and their data is retained unless deleted. To remove inactive users sooner, you can either:

• Manually delete them from the SecureFlag management interface, or
• Set up a custom Azure workflow that sends a DELETE request to the SecureFlag SCIM endpoint.
  

Okta

SAML 2.0

When enabling Single Sign-On (SSO), work with your organization’s Identity and Access Management engineer to ensure a smooth onboarding process before commencing the training program. SecureFlag supports SAML 2.0 and SCIM 2.0 provisioning This guide provides instructions for setting up Single Sign-On on Okta using the SecureFlag App available on the Okta Marketplace.

SecureFlag Okta App supported features:

• SP-initiated SSO
• IDP-initiated SSO
• SCIM 

Note: If you're setting up more than one SecureFlag application in your Okta account, contact your Customer Success Manager first, as an additional configuration step is required.

If your SecureFlag Organization has multiple subscriptions, add a custom SAML/SCIM attribute that specifies the subscription ID for each user.

Configuration Steps

1. Install the SecureFlag app from the Okta marketplace.
2. In the Okta admin page, click on the SecureFlag application.
3. In the General tab, ensure the application visibility is set up as follows.
   
4. In the Sign On tab, click on Identity Provider Metadata. Save the file and upload it in the SSO Settings on the SecureFlag platform. Refer to this article for more info.
   
5. Follow the relevant Okta guide to assign the App to Users or Groups.

SCIM 2.0

SecureFlag supports the SCIM 2.0 protocol for provisioning and deprovisioning users and teams. Work with your CSM to ensure the SSO integration's correctness before diving into the SCIM configuration. 

SecureFlag Okta App supported features:

• Create users
• Update user attributes
• Deactivate users
• Group push

IMPORTANT

Before provisioning all accounts, test the SCIM integration with a small group of one or two users. Once your Customer Success Manager confirms the integration is working, you can onboard the rest of your users.

Integration engineers: Before pushing any group to SecureFlag for the first time, whether for testing or onboarding, get email confirmation from a SecureFlag Customer Success Engineer at success@secureflag.com. Pushing a large group too early can send email invitations to every user in that group before your planned onboarding date, which can disrupt your program rollout.

Configuration Steps

1. From the Okta admin page, click on the SecureFlag application.
2. Switch to the Provisioning tab.
3. Click on Configure API Integration.
4. Enter the API Token (see this article on how to generate a SCIM API token). Then click on Test API Credentials. Ensure you receive the message SecureFlag was verified successfully!.
   
5. Click on the To App tab. Click on Edit and enable Create Users, Update User Attributes, and Deactivate Users. Then click on Save.
   

Provisioning users without SecureFlag Teams

To provision users to the platform without adding them to SecureFlag Teams, assign them directly from the Assignments tab in the Okta app.

Teams on the platform are created from Okta groups, so if you don't want team details to sync, don't use Push Groups. If you already use Push Groups, follow the steps below to switch to an Assignments-based setup. Note: Unlinking groups using this procedure does not delete any users.

1. For each Group in Push Groups click on Active → Unlink pushed group.
   
2. Select "Leave Group in the Target app" (if the Team is not empty, it can't be removed on SecureFlag). 
3. Expected final result is for the list to be empty:

User Deactivation and Deletion Process

When a user is removed from a group, app assignment, or the Directory, Okta marks them as “Inactive” in SecureFlag. This is standard Okta behavior and cannot be customized or configured. Inactive users still count toward your active license total, and their data remains stored on the platform.

To permanently delete these users, you can either:

• Manually remove them through the SecureFlag management interface, or
• Use an automated workflow in Okta (details below).

A prebuilt SecureFlag workflow for removing inactive users is available on the Okta Marketplace:

1. Go to the Okta Workflow Console. This can be found under Workflow > Workflows console from the main Okta page.
   
2. From the Connections page, click New Connection.
3. From the Connections page, click New Connection. Then, find SecureFlag.
   In the New Connection dialog, add a string to the Connection Nickname dialog. This is useful when creating multiple connections to share with your team.
4. Paste the SCIM token created in the prerequisites section into the SCIM Authentication Token field. Click Create.
   
5. Now, you have access to the Remove User License card as part of the SecureFlag Connector. Below is an example workflow that removes the SecureFlag license of a user when their account is deactivated.
   

Define Custom Attributes

You can send custom attributes to SecureFlag over SAML, SCIM, or both. For SAML, Okta includes the attribute as a statement in the assertion sent at sign-in. For SCIM, Okta sends it in the provisioning request when a user is created or updated. For the list of supported attributes, see the Custom Attributes section. Step 1 applies to everyone. Then follow Step 2 if you use SAML, Step 3 if you use SCIM provisioning, or both.

Step 1 — Add the attribute 

1. In the Admin Console, go to Directory → Profile Editor.

2. Filter to Okta, then select User (default) → Profile.

3. Click Add Attribute.

4. Fill in: Display name, variable name and data type according to the list of SecureFlag supported custom attributes.
5. Click on Save
6.  Then put values on users. For a test, edit one person directly: Directory → People → the user → Profile → Edit. At scale, map it in from AD or your HR system so it stays current on its own.

Step 2 — Create Attribute Statement (SAML / SAML JIT)

1. Go to Applications & Resources → Applications → open the SecureFlag app → Sign On tab
2. Under SAML Settings click on Edit
3. Under Attribute Statements, add another:

Field	What to fill
Name	The custom attribute you want to send to SecureFlag, e.g. sf_subscriptionId
Name format	Basic
Value	user.sf_subscriptionId

4. Click on Save

Step 3 — For SCIM provisioning

Create the field on the app profile
1. Go to Applications → select the SecureFlag app → Provisioning → To App → Go to Profile Editor
2. Click on "Add Attribute:
3. Fill in:

a) Variable name — use the same name as before, sf_subscriptionId
b) External name — the field name the app expects, e.g. sf_subscriptionId
c) External namespace - use urn:ietf:params:scim:schemas:extension:SecureFlag:2.0:User

            

Map it to your Okta user profile
1. Go to Provisioning → To App → scroll to the Attributes section → click on Mappings
2. Select the “Okta User to SecureFlag” tab
3. Find your attribute (e.g. sf_subscriptionId) and click the empty field under Okta profile.
4. Select the matching profile, e.g. user.sf_subscriptionId
5. Click on Save Mappings and then click on Force Sync to apply it to users who already exist in SecureFlag.

Alternative: set the value per group

If you'd rather not add a SecureFlag attribute to your org-wide Okta user profile, or you want different values for different populations, you can set the value on the group assignment instead. Members then inherit it from their group. This is useful when, for example, Group A should map to one subscription and Group B to another.
Before you start, complete Step 3's "Add the field to the app profile" instructions, and leave the attribute unmapped. If it's mapped from the Okta user profile, the mapping takes precedence and the per-group field is read-only. Then:

1. Go to Applications → the SecureFlag app → Assignments tab.
2. Select Groups, then click the edit icon next to your group.
3. Enter the value for the attribute (e.g sf_subscriptionId) for that group.
4. Click Save, and repeat for each group.

Two things to be aware of:

If you use SAML, the value now lives on the app user profile rather than the Okta user profile. Your attribute statement in Step 2 must use the appuser prefix instead:

Field	What to fill
Name	The custom attribute you want to send to SecureFlag, e.g. sf_subscriptionId
Name format	Basic
Value	appuser.sf_subscriptionId

Using user.sf_subscriptionId here returns nothing and the claim is omitted from the assertion.

If a user belongs to more than one assigned group, Okta applies the profile from the group with the higher assignment priority. Set the order you want on the Assignments tab, and test a user who belongs to both groups before rolling this out.

OneLogin

OneLogin SSO and SCIM Guide

1. Login to the OneLogin Admin console.
2. In the Applications tab, select Applications.
   
3. Click Add App.
   
4. Search SCIM Provisioner with SAML.
   
5. Select SCIM Provisioner with SAML (SCIM v2 Enterprise, full SAML).
6. Use the following images that can be downloaded from the SecureFlag website:
   • Square Icon: https://secureflag.com/assets/img/logo_small.png 
   • Rectangular Icon: https://www.secureflag.com/assets/img/images/secureflag-logo.png 
   • Description: SecureFlag Secure Coding Training & Threat Modeling
     
7. Click on Save.
8. Once saved, the left menu will be populated with additional tabs.
9. Click on Configuration (left side menu).
   
10. Enter the following details (leave all other fields with the default value)
    • Recipient: https://www.secureflag.com/saml.jsp 
    • ACS (Consumer) URL Validator: ^https:\/\/www\.secureflag\.com\/saml\.jsp$
    • ACS (Consumer) URL*: https://www.secureflag.com/saml.jsp 
    • Login URL: https://www.secureflag.com/login.html 
    • SAML not valid before: 3
    • SAML not valid on or after: 3
    • SAML initiator: OneLogin
    • SAML nameID format: Email
    • SAML sessionNotOnOrAfter: 1440
11. Click on Save.

SCIM Configuration

1. Click on Configuration, then enter:
   • SCIM Base URL: https://api.secureflag.com/rest/scim/v2 
   • SCIM Bearer Token: [Your generated SCIM token goes here]
   • To generate your SCIM token on the SecureFlag Platform, check out section SCIM 2.0 Provisioning above.
     
2. Click on Enable.
3. Click on Save.
4. Click on Parameters (left side menu).
   
5. Change the value of scimusername to Email.
6. Click on Provisioning (left side menu).
   
7. Click on Enable Provisioning.
8. Click on Save.
9. Click on More Actions > Click on SAML Metadata.
10. Install on the SecureFlag portal, more info on that here.