Say I've added a new resource to protect with IAP, and a new tenant. I want to do this for each new client that I onboard, to use external identities, and allow them to control their own users. I can't be logging into the cloud console each time to add a new client (I can see that users for a tenant can be managed by API). Any ideas?
have you evaluated using Identity Platform with IAP for authentication, https://cloud.google.com/identity-platform/docs? At the IAP-protected resource, you may change the auth to use IdP instead of the default Google Auth.
With IdP you can leverage the external identities of multiple providers that your customer would control.
Related
There are established and popular protocols for identity providers to provide a client with properties about the logged in user.
For example in OpenID Connect (OIDC) the client can request access to certain scopes and then read claims about the authenticated user. The use case is the usage of centrally maintained user data, like name, department, e-mail etc.
I'm looking for way for the client to write custom properties about the authenticated user back into the identity provider.
Use cases:
a client application needs to save some app-specific preferences about the user and
a client application enables to user to edit some existing properties that are relevant for other client applications, too
(Yes, it would be trivial to design my own REST-like endpoint for this, but I'm looking for an open standard, in order to make it easier for clients.)
Have a look at System for Cross-domain Identity Management, aka SCIM. This is an out-of-the-box Rest API that an IDP should provide, and which should also enable you to save custom attributes against users.
Typically it is called by back end components, which use the client credentials grant to get a separate token with which to call the SCIM endpoint.
Our OAuth client application is built with Spring (through JHipster). The OAuth provider only serves the authentication functionality, but not the authorization functionality. Ideally, we should only allow a small group of people to access our OAuth client application, but not all those users who can sign in to the OAuth provider.
A solution I can think of at this moment is to create a custom user role to control the access in the OAuth client application. That, however, only can be done after the user's first sign-in when the user account data is created in the application.
Any better solutions?
Ideally you would apply user access control before creating user account data is created in the application. You could do so by providing an application specific scope or claim in the token that is generated for your application (aka. Client). Upon receiving the token, the application would check for the required attribute in the token before allowing access.
I have created a Single Page Application with Angular and authentication/authorisation is managed by Azure AD. I have used MSAL.js to initiate the implicit flow.
Everything is working fine, but now my client wants to use her own identity provider (IDP) so that users have a single point of entry for all apps (including mine). This IDP is not mainstream, it is built in-house by the client;
I want to keep using Azure AD to manage authorisations (groups, roles...). I also want my application and its dedicated backend API to be registered in Azure AD, not in the third-party IDP.
Azure AD should remain responsible for providing the Access Token to the SPA in order to call the API.
Somehow, I should redirect the user to the third-party IDP login form and upon successful login it will redirect to my SPA, which should then associate the tokenID with an AzureAD account and retrieve the Access Token (I suppose I will have to create an account in Azure AD for users identified in the third-party provider)
However I'm having a hard time figuring out how to achieve this and if it is at all possible ?
What would be the recommended approach for this scenario ? Can I still use MSAL.js or do I have to rely on something else ?
ARCHITECTURE
Your goals are completely correct and you should not need to change a single line of code to integrate a new IDP - so you can continue to use MSAL.js.
PREREQUISITES
In order to integrate their own IDP into your system you need to insist on certain prerequisites:
The client needs to provide a Standards Compliant Identity Provider
Typically the IDP needs to communicate with your Authorization Server (Azure AD) via either Open Id Connect messages or SAML2P messages
A home grown IDP may not meet these prerequisites in which case you need to explain to the client that they need to get standards compliant.
HOW FEDERATION WORKS
Your UI will redirect to your AS
The AS will redirect to the IDP, when given a trigger
The user will authenticate in the IDP
The IDP will post a token to your AS to identify the user
The AS will issue another token to your UI
Note that there is no coding involved here - there is only standards based integration between vendor systems.
WHAT THE CLIENT WILL GIVE YOU
Client details are often supplied by giving you their metadata document, and these details are then configured in Azure AD as a trust entry:
The entity id of the IDP
The token signing public key for IDP tokens, so that your AS can validate them
A URL to redirect to
WHAT YOU WILL GIVE THE CLIENT
A similar trust entry will need to be configured in the client IDP so that it trusts requests and issues tokens - though no certificate is usually needed here:
The entity id of the AS
A URL to post tokens to
TRIGGERING THE REDIRECT FROM THE AS TO THE IDP
One option is to forward the entity id to the authorization server in Open Id Connect redirects. Often an 'idp' query parameter is used, something like this:
Client accesses your app with a bookmarked URL:
https://app.mycompany.com?idp=urn:client.com
You add an extra parameter to the Open Id connect redirect to tell it where authentication should happen:
https://login.mycompany.com/authorize?client_id=XX&idp=urn:client.com
AZURE AD SPECIFICS
Once you understand the high level process there is some technical stuff to configure the connection and you'll need to consult vendor documentation, such as this Microsoft Azure B2B article.
PRACTICE
If you haven't done this before then you need to invest some time to get a connection working and then document the process.
You can use Windows Server and ADFS to simulate a client connection, then integrate it as a SAML2P connection. There is a learning curve though, and you'll need infrastructure such as ADFS certificates.
CompanyA is integrating with CompanyB where CompanyA's users will be buying devices of CompanyB.
CompanyA wants to show user's device(CompanyB) details on their app by calling
CompanyB's API on each user login.
CompanyA user is authenticated on CompanyA IAM.
CompanyA has to call register device when user tries to add an device first time.
Help me to identify the flow which i can use to query particular loggedin user's device only.
Do i need to create duplicate user account on CompanyB's IAM?
If i use client credential flow for API to API call, access token given by CompanyB is only provides access for API calls but it does not tell that on behalf of correct user only call is invoked.
Assume that CompanyA uses IdentityServer or any other provider as IAM and CompanyB uses Azure AD B2C.
Any other approach?
Please see below diagram,
You should be able to do this by making the Company B API multi-tenant in their Azure AD.
There are other options surely, this is just the first one that came to my mind.
Overview of the multi-tenant pattern
You would have to do admin consent on it to get the API's service principal in your Azure AD tenant.
The Company B API can give you an endpoint for doing this, redirecting you with the proper parameters to the authorization endpoint. How to send a sign-in request
After doing this, you should be able to then require permissions on the API from Company A API in your tenant (configured in Azure AD).
Configure a client application to access web APIs
After doing those things, your API should be able to use On-Behalf-Of grant flow to get an access token for Company B API.
Using Azure AD On-Behalf-Of flow in an ASP.NET Core 2.0 API
Company B API must be configured to accept access tokens from another issuer than their Azure AD of course.
In general multi-tenant scenarios, the issuer validation is commonly turned off.
If Company B wishes to have control over this, currently they will have to explicitly list the valid issuers.
Issuer values look like this: https://sts.windows.net/31537af4-6d77-4bb9-a681-d2394888ea26/, the GUID is your Azure AD tenant id.
The Company B API can extract the tenant id and user object id from the access token, and authorize the user to resources based on them.
I was looking at the AWS side and looks like they have something that could meet the requirements
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html
Was wondering if something like this exists in Azure.
we have an existing "private/internal" API (non MS/Azure) that we would like to protect with oAuth2 provided by Azure AD, so, that the user's access to the API could be maintained by the Azure AD administrators.
It seems like the way to do this is to configure the API as a web application in the Azure AD. Then, users can get the authorization token from the Azure oAuth2 server and send it to the api (e.g. from a single page web app).
The API is expected to validate the scope, as per my understanding, received in the token and make a decision regarding the access.
But I can't figure out how to configure the API access scope in the Azure AD against a user. I.e. how to link a particular user and the API scope in Azure AD?
Can someone pls advise?
Thank you.
When you configure the app, you can enable "User assignment required" (in the Enterprise application Properties in the Azure Portal), and then configure which users or groups should have access.
Alternatively, if you need more granularity, you can use the Role based access, where you define roles in the application manifest (https://learn.microsoft.com/en-us/azure/architecture/multitenant-identity/app-roles), and then assign users to the different roles.
The [Authorize] attributes on the API controllers or on actions in them can then be configured with the required roles to access them, like so:
[Authorize(Roles = "Admin, Writer, Approver")] (any of the three named roles have access).
There is a sample which demonstrates this.