Impersonate Google Cloud Patform user through OAuth2.0 flow - security

I want to set up an OAuth2.0 flow for users that have access to GCP.
The user will login to a web app.
Then, the OAuth2.0 flow will need to ask for the consent that will allow the app to perform things on their behalf, based on their permissions.
Therefore, the scopes that need to be requested should be those that cover their actual permissions on GCP.
Is something like that possible when it comes to OAuth2.0 and GCP?

Had you seen? https://developers.google.com/identity/protocols/oauth2
Looks like that might address your question.
Separately from that link --> Yes that is something that could be done. You login via OAuth, and once authenticated that service can use GCP Service Accounts https://cloud.google.com/iam/docs/service-accounts to work with GCP Services.

A user can be granted permission to impersonate a service account.
A service account can be granted permission to impersonate a user account via Domain Wide Delegation (Google Workspace).
A user cannot impersonate another user. There is no mechanism to grant the required permissions.

In a GCP project you can access Google APIs using these types of credentials:
API keys
OAuth 2.0 client IDs
service accounts
So, to answer you question, using OAuth 2.0 in GCP is certainly possible.
However, without knowing what data your application needs to access, it's hard to tell if it's more appropriate to use a service account or an OAuth 2.0 client. In a GCP project, if you go to APIs and services > Credentials > CREATE CREDENTIALS > Help me choose, a wizard will guide you through the process of creating the most appropriate credential for each authentication scenario:
Lastly, when you say this:
for users that have access to GCP
Do you mean that these users have a Google account that can access the Google APIs used in your project? If that's the case, and your project doesn't need to access user's data, then a service account might be a better choice than an OAuth 2.0 consent screen. I think you could let a service account impersonate a user via Domain Wide Delegation, but please keep in mind that Google itself discourages this feature.
See also Create access credentials.

Related

Is there an OAuth flow that doesn't require a client_id?

I have created a Microsoft Teams bot built using a Golang port of the Bot Framework. It is a multi tenant bot which lives in my infrastructure.
It is easy to add the bot as a "Teams Application" by selecting it from the marketplace (for free), however, to function correctly it needs additional Microsoft Graph permissions. Specifically read the title of a MS Teams Channel / Group Chat.
This seems to be a challenge for users as almost no one - even those 'in IT' seem able to correctly add the permissions required, even with documentation.
I've been helping them personally but it's not a commercial product so not viable in the long term.
I would like to find an OAuth2 flow which would allow a privileged user to authenticate with their Azure tentant and grant the necessary privileges for my application to do it's thing. Or, alternatively create the client registration in advance of installing the bot.
Every OAuth2 flow requires me to have (or know) my client_id before making the request. Given it's in the users Tenant, I don't have access to it; the users can authenticate against their Azure AD tenant though, so they must receive a bearer token which would allow them access to create or update permissions on an Azure Application.
There is chance to use the OAuth 2.0 client credentials. This grant is specified in RFC 6749. This grant is to access the web hosted resources. This resource will directly identify the application based on the identity of the application. In server-to-server communication we can use OAuth 2.0. This can be referred as "Service accounts" or "Daemons".
Microsoft identity platform and the OAuth 2.0 client credentials flow

How do I programmatically login or get the JWT token of a logged in Google user in Azure AD?

I already setup the Google Identity Provider in Azure Active Directory and can invite users to my application. After the Google user accepts the invitation, I can see their user object in Active Directory. What I would like to do next is to programmatically login the user using the Google federation or get the JWT token of the logged in Google user.
For user objects created in AD, I can programmatically login the users using ROPC. I understand this is not possible for external users authenticated using Google federation.
• Kindly please take note of this that Azure AD does not support ROPC flow method of credential authentication for federated accounts. Also, when you are using ROPC method, your credentials are at risk of compromise as they are passed directly in the body of API authentication request. Thus, I would suggest you use client credential flow for this purpose as it can access the data from both sides.
• Since you want to programmatically login using the Google federated user to some application or SaaS platform, I would suggest you refer the below link which describes sufficiently how you can use the federated domain’s user login credentials to login to an application or a SaaS platform. In this link, it is stated that you should configure the Azure Policy regarding the Home realm discovery to false and configure the federated domain as its preferred domain for logging in. Also, if you want to retrieve the access token only, then you can use the ‘Postman’ application or ‘https://jwt.ms’ as the redirect URI for that purpose.
https://medium.com/#amanmcse/ropc-username-password-flow-fails-with-aadsts50126-invalid-username-or-password-for-federated-90c666b4808d

Azure AD app - client secret connected with user

please, is here any way how to make relationship between applicaiton in Azure AD and User with client secret.
My use case. User ask for token with client secret(as deamon) and call my web api and a verify this token. Token is valid but there is no information about user who call it or who registered app. User gets token via API (https://learn.microsoft.com/en-gb/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow#get-a-token)
When user ask for token interactive everything is ok.
I tried to use a information about who created app, but Azure AD does not set it when user is administrator.
Is there any way how to use deamon which will be connected with some user?
Is there anywhere i can save this relationship in azure AD?
My idea, every user who wanted use my web api as deamon create his application and connect to mine web api, which use his app for verification. Relationship between app creator and user can be enough. but when i delete user and he has still client secret, he can access. I dont want to use his username and password because it will be saved on different computers and it is not save enough.
If you have more questions, dont hesitate to ask!
Thank you for any idea.
For scenarios, such as this one, your application should have an App Role with the allowedMemeberTypes having Application and as mentioned in the docs, this will show up as an application permission to other apps.
So the consumers of your API will have to add this application permission to their daemon app (which requires admin consent). This will trigger a flow internally that creates a Service Principal (like a user persona of the application) and adds that as a user to your application (you should be able to see it listed under Enterprise Applications > (Your API) > Users and Groups).
When you want to deny this daemon access to your API, you will just have to revoke the admin consent provided at first.
I believe you could even automate this process by using the Microsoft Graph APIs.

Secret Key / Access Key with Azure Active Directory, enterprise application, app roles?

We are working on WEB APIs and want to integrate Azure AD for AuthN and AuthZ. We have successfully integrated the same. We have created enterprise applications, custom roles, assigned users for the same.
Now we need to allow access to APIs with AWS like keys (Secret / Access keys). Individual user can generate their own keys and store those in Azure AD so that when those keys are used, user can be authenticated.
I didn't find any way to achieve this using Azure AD. Any suggestions around same are welcome.
Meanwhile I have gone through custom store for keys. Please refer link : https://www.codeproject.com/Articles/1228892/Securing-ASP-NET-CORE-Web-API-using-Custom-API-Key
Thanks in advance.
Azure AD authentication uses tokens.
So any app wishing to call your API must authenticate with AAD and acquire a token for the API.
If these users are making apps within your organisation, then they can register their app in your AAD and require access to your API. They will create and manage their own keys.
If on the other hand these users are making an app for another organisation, you'll have to make your API a multi-tenant app.
And you'll need to have an on-boarding page in your API through which you will redirect their admin/user to the AAD login page, where they will consent to any permissions your API requires.
After this a service principal is created in their tenant.
Then they can register their client apps and require access to your API.
They will have full control which permissions they want to assign to each app, what roles to give to users etc. But of course the tokens will contain their tenant id so you can filter access on that.

Azure Active Directory SSO - Account Mapping

iam currently researching how to implement Single Sign On for our WebService.
This is what i came up with so far.
If a customer of our WebService has an AzureActiveDirectory they can log on with their active directory user account to our WebService if we provide the nessecary interfaces for SAML, Oauth2, OpenID or whatever authorization protocoll we chose and azure supports.
The customers could also have their local network Active Directory synced to their Azure AD and use their Domain accounts to log on to our WebApplication.
Customers need to use the myapps.microsoft.com portal to "wrap" authentication.
Once everything is set up correctly the Identity Provider (AzureAD) would provide use with (e.g) an authenticated User Identity.
Here is were my problem begins.
Of course i need to somehow map the identity provided by the AzureAD to a certain Account for our WebService - we cannot simply use the provided identity.
As far as i understand it, you can grant AzureAD the right to create an Account on the target WebService in the name of the user which is currently signing in.
(Its called : enabling automatic user provisioning in the azure management portal).
However, when testing this with the Box, Canvas or Google apps i failed. Either i got an error or in the case of google apps i was just promted to login with my azure AD test account and then asked for a password and username of my google account (i set up SSO as an azure AD trust relation- so this should not happen)
Can someone provide some insights on how to accomplish the following?
Once the user is authenticated by SSO I want to create an account for our WebSerivce and then save the credentials for that user only in the Active directory of that particular user.
So if the user logs in the second time we can check wether there is an account already existing and log in the user with this account.
(I was told by microsoft that this might be possible with Azure Rights Management, but i cannot really find good documentation on that)
Storing the relationship: "Microsoft AD Identity <-> our WebServiceAccount Credentials" on our side is not desired because we cannot securly encrypt the data in a way that we DONT know whats in there. (or there is , and i dont know of it yet)
"Bonus Question":
Can i support SSO for a desktop application too? (Do i need a provide proxy web application or can the desktop app do this directly?)
Please see my answer to a similar question here: asp.net azure active directory user profile data
However - I'm trying to understand if you need something different. Are you expecting your customers to already have a directory and Azure AD accounts (maybe through having Office 365 subscriptions), and use those to sign in to your web app, or does your app scenario require creation/provisioning of user accounts into your customer's Azure AD directory? Provisioning can be done through graph API (as per your link), as long as the admin of your customer grants consent to allow your app to write to their directory. You can find some samples on github, and I recommend you look through https://msdn.microsoft.com/en-us/library/azure/dn499820.aspx and https://msdn.microsoft.com/en-us/library/azure/dn646737.aspx for code samples.
HTHs,
I think, without testing it. That using the Graph API enables me to save custom data for any Directory User effectively enabling my desired functionality.
This is the documentation i found very usefull.
https://msdn.microsoft.com/en-us/library/hh974476.aspx

Resources