Starting today, Access clearly displays why a user was blocked. There are two areas we now display detailed information about a policy decision:
Let us know if you have any feedback or questions as you try this new feature out!
For me the test work only when I test with the email I’m currently having an open session with.
When I test with any other user email on the same Okta, same email domain and we all have the same rights, I have a denied access and the user infos on the detail view are all empty.
Has the user you are testing with authenticated to an Access application before? If the user is not yet in the list of My Team → Users then it will show as Access Denied because we don’t have any information about that user yet.
But then what’s the use of external IdP if we also have to have the users in My Team?
I’m not sure to understand the role of the My Team database.
I thought that using an external IdP was enough to rely on the IdP database of authentication and then CF Access only provides the authorization based on policy rules (here the rule is just on the email domain and Okta being required).
So does it mean that we have to have the users in both databases, my IdP and CF My team, and then how can this be automatically done?
Thanks for your help!
Authentication does rely on the IdP. It’s unpossible for a ‘test’ button in a Cloudflare dashboard to fake a login as user to your IdP with no credentials and retrieve details. But if a user has logged into Access previously the returned data (e.g. groups) could be evaluated against the current policies.
Hum, that explains the test part thanks.
But what about the need to have infos in My Team? Couldn’t access only rely on IdP and call each time? Is this some sort of caching?
My Team isn’t actually a thing. It’s a list of user/identities which have logged into via an Access policy (or via the Warp client which is also really just an Access policy). If there is info there that matches a policy then it might be able to determine if that user would have been able to log in successfully with a specific policy’s current settings.
Ok, thanks. I will dig through why Okta doesn’t even leave a trace in My Team and access logs then.
It does when the user logs into the app. But the test button can’t log in as a user.
yep, I get that. Logic.
But I guess My team is not only for being able to “replay” policy test.
Apologies, I should have been more precise when recommending My Team->Users. The Users list is where we store all identities that we have seen from the identity provider. Any user that has logged in via Access will appear in that list of Users.
If a user gets blocked by Okta then we won’t see that user’s information since the authentication failed before any SAML or OAuth was sent to Access.