Providing update to ensure that deprecation is handled by anyone doing copy-pasta of the custom OIDC provider.
Signed-off-by: CiscoRob <133238823+CiscoRob@users.noreply.github.com>
Since #22549 adds this API to the core framework, integrators don't need to
define their own.
Signed-off-by: Jamie Klassen <jamie.klassen@broadcom.com>
The provider.id is used as the backend auth endpoint, which is added in this same guide. The default provider id is `github`, which will point to the wrong auth endpoint. Without modifying the core package code, this guide will not work without this additional configuration line.
Signed-off-by: devonpaluso <55293990+devonpaluso@users.noreply.github.com>
Microsoft have renamed Azure Active Directory to Entra ID. https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/new-name . This PR updates references to AAD to refer to Entra ID.
* On each documentation page, I include `formerly Azure Active Directory` in the first non heading reference to Entra ID. This will help anyone unfaimiliar withthe name change, and will also mean the page continues to show up in search results if people search for the old name.
* I didn't correct references in file names, as this would cause broken links. If we have a way of redirecting those to new urls I can look at doign that, but if not, I think it's better to leave existing links working.
* There were a few references to AAD in release notes for older versions - I left these alone as the product naming was correct at the time of the release notes.
* LDAP provider still has references to "Active Directory" as these reference to the on premise Active Directory, not Azure Active Directory
Signed-off-by: Alex Crome <afscrome@users.noreply.github.com>
When a user is logged in to multiple microsoft accounts, there can be be a little bit of friction in the Entra login process as users will be asked to select the account to login with.
Scenarios in which a user may have multiple microsoft accounts
1. Someone logged in to your work Entra ID account, and a personal microsoft account
2. A consultant who has an Entra ID account at both their employer, as well as the company they're contracted out to.
3. A user has a regular account, as well as one or more high priviliged accounts.
When a domain hint is provided, Entra will filter out all the accounts which don't belong to the tenant specified on the `domain_hint`.
In many cases, this will filter to a single account, avoiding the need to select an account at all (e.g. scenario 1 & 2).
This won't always happen (e.g. scenario 3).
Additionally in the case a tenant has been configured to federate authentication elsewhere (e.g. to an on premise AD FS), setting the domain hint means entra can send the user straight to the federated authentication soruce, removing further steps
If backstage is allowign authentication from multiple tenants, this field should be left blank.
For more details, see https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/home-realm-discovery-policy
99% of the time, this value should be the same as the tenantId, so we could get rid of hte domain hint, and set it to the same value as the tenant id automatically.
We'd need to provide a config option (e.g. `isMultiTenant: true`) to opt out of this.
For those edge cases, this would be a breaking change.
I decided to go with specifying the `domain_hint` seperatly for now just in case my assumptions are wrong and there are more cases wher ehte `domain_hint` will get in the way.
We can always make this the default behaviour later on.
Signed-off-by: Alex Crome <afscrome@users.noreply.github.com>
* Add API Permissions to the app registration setup
* Encouraged re-use of an existing app registration over creating a new one.
* Moved the `Adding the provider to the Backstage front end` higher up so it's not so easily missed
Updated the microsoft authentication document to include details on adding API Permissions.
At more relaxed companies, these permissiosn will be silently added to this list the first time they're requested, however in more locked down companies, a directory admin will need to consent to these permissions before users can use them.
Also slighlty reworked the docs to encourate re-using any existing app registration. This includes renaming the `AUTH_MICROSOFT_*` variables to match the `AZURE_*` ones used throughout other azure integrations.
Signed-off-by: Alex Crome <afscrome@users.noreply.github.com>
YAEGASHI Takeshi