This is a demonstration of an Atlassian product (Bitbucket) executing SSO against Azure Active Directory, over OAuth.
In the procedure that follows, I use the email
field as a user ID.
This allows us to get up and running quickly, but this is not ideal.
Microsoft outlines recommendations here.
In summary:
- User IDs should not be human-predictable, but instead GUIDs
- Why:
- Anything human-predictable/readable (name/email/etc) is also human-modifiable, so users could lose control of their account when modified, or users could take over other user's accounts on rename collisions
- Anything human-predictable/readable causes collisions across domain contexts
- The same email in different Azure Tenants (think unique Active Directory servers) represents a different account
- This gets worse with simple usernames
- Problem for us: Bitbucket needs a username, and it's very odd to not have a meaningful one
- Maybe another Bitbucket SSO Plugin (
re:solution
orminiorange
) would allow us to define a richer mapping logic (identify user via UID but use something else a username) - Maybe having an LDAP connection in addition to the SSO would allow us to define a richer mapping logic (automatically identify user via UID but use something else a username)
- Maybe another Bitbucket SSO Plugin (
- Problem for us: If we use an Azure-originated GUID, we can only pre-provision users with queries to Azure
- We could experiment with the JIT Provisioning feature of Bitbucket Authentication Methods
- Why:
That being said, here are the fields that Azure provides:
${sub}
:- This is a UID that uniquely identifies the combination of:
- Azure User
- "client" (App Registration within Azure I believe)
- Azure Tenant
- This is not an ideal UID because we want a UID that works across App Registrations
- I'm not sure how you deterministically generate this for a given user (I was only able to capture the raw value in error logs in Bitbucket)
- This is a UID that uniquely identifies the combination of:
${oid}
: The UUID of the Azure User${tid}
: The UUID of the Azure Tenant
It looks like the best non-human readable GUID might be: ${tid}-${oid}
I saw this error frequently:
... Unknown state in response ...
... but I believe it is a red herring, from this pattern of execution:
- We fail to login and get kicked to an error page
- We attempt to login again (by clicking the "login" button), which tells the webpage to redirect back to this page after logging in
- We successfully login, and Bitbucket redirects back to the error page, but the error page is not actually relevant to our current (successfully authentiated) session
Setup a Account and Tenant in Azure
Defined Bitbucket OAuth Client Secret in Azure AD
Exposed Azure AD to Bitbucket through OAuth
Added Azure AD OAuth to Bitbucket
Added OAuth Redirect URL to Azure AD for Bitbucket
Added OAuth Token Claims to Azure AD for Bitbucket
Defined User and Group in Azure AD for Bitbucket OAuth
Defined User in Bitbucket for Azure AD OAuth
I was able to login to https://bitbucket.proxy.auth-demo.docker/
through the Demo Azure OAuth SSO button
(providing the Azure password for first.user
when prompted by Microsoft).