Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Jira, Confluence and Bitbucket offer anonymous users to view public content without having an authenticated session.

Enable SSO-Verified Anonymeos Access in KSSO to allow users who do not have Jira or Confluence accounts to access JIRA/Confluence anonymously while still benefiting from the security features of Single Sign-On. This enables your organization to save on license costs while maintaining secure access to all your content.

SSO-verification means that the users are not accessing Jira or Confluence truly anonymously since their identity is known. A session cookie is created the same way as in a regular login, except that the session is not related to a local user in the host product. With this feature enabled, it's important to note that truly public content is restricted. Accessing any content now mandates users to have an active session, ensuring a more controlled and secure environment.

Configure SSO-verified Anonymous Access in Kantega SSO Enterprise

Prerequisite

Anonymous access must be enabled in Jira/Confluence for this feature to work.

Examples, anonymous access in Jira and Confluence

image-20240214-145407.pngSkjermbilde 2024-09-04 kl. 12.46.06.png

Users that require editing rights will have to be provisioned with a license group in Jira/Confluence. This way only the users needing to edit will consume a license while those not created in Jira/Confluence will be given an anonymous access session as fallback.

Step - by -step Guide

  1. Select Identity Providers in the KSSO menu and choose the applicable Identity Provider in the overview page.

    Skjermbilde 2024-09-04 kl. 14.50.55.png

  2. Enable SSO-Verified Anonymous Access in Kantega SSO Enterprise.

    image-20240214-145820.png

  3. Enable Force login in Kantega SSO Enterprise.
    Select Common → Force login. You must enable force login to require anonymous users to login.

    force login.png

  4. Configure Known domains in Kantega SSO Enterprise.
    Hvis brukerkontoen finnes i JIra må du velge alternativ 3

    Known domains.png


    We recommend If the user account exists in JIra, you must choose option 3 “Trust identity provider to log in users only from the known domains”
    You can trust the Identity Provider to log in users only from the known domains, but fallback to SSO-Verified Anonymous Access for other users.

    image-20240214-145240.png

    See also how to make users not in known domains stay anonymous.

f

Skjermbilde 2024-09-03 kl. 13.06.40.png

Skjermbilde 2024-09-03 kl. 13.07.36.png


Configure SSO-verified Anonymous Access in Kantega SSO Enterprise

  1. Select Identity Providers in the KSSO menu. The Identity Provider overview page is shown.

    Skjermbilde 2024-09-03 kl. 13.25.49.png

  2. Choose the Identity provider you want to configure, then select SETTINGS → SSO-Verified Anonymous Access. Enable the switch SSO-verify anonymous access.

  3. As pointed out in the above screen, Anonymous access must be enabled in the Atlassian product (here Jira or Confluence) for this feature to work. Open administration of Permission schemes in your product and check that Anonymous access is enabled.

    Example: In Jira, grant permissions to group, Anyone on the web to allow anonymous access

Skjermbilde 2024-08-21 kl. 14.44.29.pngSkjermbilde 2024-08-21 kl. 16.12.17.png

Configuring related settings in Kantega SSO Enterprise

The Just-in-time provisioning settings affect how SSO-verified Anonymous Access works since both features are related to the presence of user accounts. If Just-in-time provisioning is set to create users, this will take precedence over anonymous access.

The Group Memberships settings allow configuring conditions for when the user is created. This can be configured fluently with SSO-verified Anonymous Access. For example, you can configure a policy in which users and group memberships are created automatically for all users logging in and belonging to the editor group in your identity provider. In contrast, all other users will fall back to “anonymous access” after logging in with SSO.

User login with IDP

  • No labels