Hello, @Dani_Panteliades
Site access without product access is free on your bill for the site products, but will be billed for on your Atlassian Access (if you have it) bill, unless the user is listed in the Access's non-billable policy (see: https://support.atlassian.com/security-and-access-policies/docs/understand-authentication-policies/#Authenticationpolicies-Whatisanonbillablepolicy)
A user can be invited to the site by the site admin, without any product access given.
Example: a JSM Portal Only user who has been migrated to Atlassian Account. Ordinary a JSM Portal Only user will have a password specific to this JSM instance e.g. if you have to login into multiple Cloud-based Service Desks of different Atlassian Marketplace Vendors (to get support for their apps) – you'd be using different passwords, despite using the same email as the Atlassian Account you use to access Community here.
SAML SSO integrations with Identity Providers (e.g. with Azure AD or OKTA) that Atlassian Access enables do not apply to Portal Only users.
If your account has been migrated to an Atlassian Account within the JSM instance (in this example, every vendor will have to do this for their respective instances) you would be using the same credentials as you use for Community. Such users will have site access. To stay Portal Only they will not be a member of any group that would give them product access.
This becomes extremely important for organisations that do want to use SAML SSO and enforce security controls not only on JSM agents, but also on JSM customers, e.g., internal IT service desk use case.
On the other hand, a user with product access, will always have site access to the site which contains the products, unless site access has been explicitly revoked.
When you invite a user to the site manually, you can give them product access simultaneously. Here you are trying to give site access first, and end up giving product access too.
This usually applies to user external to your organisation, the ones you don't manage in any way, except inviting and uninviting by removing site access (and leaving them still listed on your site, but with a confusing "no site access" status)
Managed users from your own organisation these days are mostly coming from an Identity Provider via Atlassian Access (and would use SSO too).
When users are automatically provisioned from the Identity Provide via SCIM using Atlassian Access User Provisioning (see: https://support.atlassian.com/provisioning-users/docs/understand-user-provisioning/) they get site access if the IdP pushes along group memberships that would give them access to products on this site. Here you give them product access first and end up giving site access too.
Please note Atlassian Access is cross-site, Atlassian Cloud wide. A user may be pushed from the IdP, with 2 group memberships, where one group gives product access to Jira on site A thus giving site access to site A, and the other group gives access to Confluence on site B, thus giving site access to site B. Because of this it's important to include the site name into the names of the groups that the IdP is pushing.
To complete this explanation – if a user has access to a site by virtue of being given product access via product access group membership, site access can be revoked by the site admin.
This will effectively result in product access being revoked too, despite the user still being in the product access groups. This is similar to deactivating the user, but only in the scope of one site, as opposed to Atlassian Cloud-wide action.
Hope this helps!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.