I'm curious if it's possible to gain access to the Gmail settings of all users within a domain once a user with Admin access authenticates. I know using the Admin SDK, you have access to user settings, however, I'd like to setup email forwarding and it doesn't seem like it's possible without each user authenticating.
You may refer with this SO thread. Before you can call the Gmail API you need to use the service account "JWT flow" in your code to retrieve an OAuth2 credential for the Gmail user you want to access. Here is the documentation. You may also check this related post.
Related
From the documentation it seems that using an application that is in the B2C tenant and thus hosts user accounts that there is no way to directly access Microsoft Graph API via a logged in user per their own context.
I want to establish the use case properly so that the solution is that which makes the most sense.
The use case is that if a user wants to edit claims for example such as permissions they would be able to do so while logged in through Azure B2C.
The flow would be. Logged in user -> can change certain claims information such as address, surname, and other custom policy fields (SEO contact permissions.)
Is the proper way to do this is to build a proxy that will take the application's AD application permissions which are allowed to call out to Microsoft Graph and pass along user context so that the scope will be limited to that user only?
For example. User logs into the app.
The app has AD permissions that are granted admin consent
Create a client secret to prove application identity upon request of a token
Now can access Microsoft Graph api
Ref of Registering an app with Microsoft Graph api
What's not clear here exactly is the next part. My user is logged in with Azure B2C. Should I just pass along their id token which has their claims to the application? How do I put in scope/context of the logged in user of the app permissioned access to Microsoft Graph?
This part is not clear in any documentation.
I don't want a logged in user to have access to everything.
Is a proxy the only way to do this?
If a proxy is the only way to do this what identifier or id is what should be used to pass along to the query to assure only that user is in context?
Am I thinking of this incorrectly and or is there a better way to do this other than a proxy?
The documentation says this.
Apps that have a signed-in user but also call Microsoft Graph with their own identity. For example, to use functionality that requires more elevated privileges than the user has.
That doesn't fit exactly into my use case above or address it really but I think it is related. The functionality should be considered to be an elevated permission but to the scope of the user. This user can change this claim via their own logged in entity. What do you call that and what is the best way to solution this?
Lastly, is there anything that should be known in the MSAL library including Angular and React that would be useful in this process? It seems like I will have to converge the 2 to obtain the access token of the app and of the person and proxy those out to a backend service (the proxy) to then do a body of work.
Am I thinking of this correctly?
This Stack is the closest to relevance but doesn't ask or solution the entire use case as I have here. But is useful for illustrating the confusion.
"Logged in user -> can change certain claims information such as address, surname, and other custom policy fields (SEO contact permissions.)"
Why can't you use the Profile Edit user flow? You can configure what attributes the user can change.
So if I have an app with many users on board, all from different companies/places, I'm thinking that an individual 'connect to docusign' with OAuth is the right flow.
I think I could have an admin connect their account and impersonate the entire company, but it doesn't sound great from a security perspective.
I also see some places asking people for their docusign admin username/password which I assume is highly discouraged.
Question: I am planning on using just one 'integration' for my app to manage all this, should I be aiming to use one integration per docusign account I interact with? i.e. Should I ask the companies to each make an integration and give me the id/secret?
Several questions here:
OAuth flow
Yes, if your DocuSign users will have their own DocuSign user IDs then you can add a "Connect to DocuSign" button and use the OAuth Authorization Code grant flow. Include the extended scope so you can use the refresh token on an ongoing basis. Remember to use secure non-volatile storage for the refresh tokens since they can be used to obtain access tokens.
See Authentication for ISVs
I think I could have an admin connect their account and impersonate the entire company, but it doesn't sound great from a security perspective.
Correct. It is best to use JWT grant (impersonation) only if the end users can't use the Authorization Code grant flow. For example, if your app is a back-end app or doesn't have a web interface.
JWT (impersonation) flow is fine when needed, but it incurs significant customer confusion and work to provide consent. So Authorization Code grant is preferred if it fits your needs as an ISV.
One DocuSign client_id (integration key) or one per end-customer?
Best is to use one DocuSign client_id (integration key) for your application, not one per customer. See ISV docs
Should I ask customers to give me an integration key and secret that they created?
Please no. Your customers are not developers. Asking them to become DocuSign developers and create a client id (integration key) is a lot of work for them. There's no need to go down this path. Just use the same OAuth Authorization Code grant redirect_uri for all of your customers. Remember that you can use the state parameter as needed to handle the OAuth redirect from DocuSign.
Use your free partner account to manage your application's client id and its settings.
asking for a DocuSign administrator name/pw from your customers
Correct: don't do that!
you want your customers to set up their DocuSign accounts in a specific way
Your app can do that for them by having including a "Setup DocuSign account" button. That button (when used by an authenticated DocuSign admin) would update the account settings as your app needs. For example, setting up a Connect
users have multiple accounts
Extra: remember that it is common for DocuSign customers to have access to multiple DocuSign accounts. Eg, a general account, an account for HR, etc. They may or may not set up a special account for your application, depending on the use case.
After a user authenticates, your app can either use the user's default account, or if your application uses a dedicated account, check that the user has a access to it.
I'm struggling to figure out a way to hook into the authentication/authorization/token issuance process.
I want to be able to authenticate users, as well as prevent users that are banned from logging in.
I want things to work this way:
Upon providing their username + password, users get logged in if the credentials are valid
If the credentials are valid, we do an additional check as to whether the users are banned or not (by checking their username in a custom database)
If the user is banned, deny login
I want to know whether Azure AD or Azure AD B2C supports this ability to hook into its processes, and if so, where can I find more about it? documentation? sample code? etc...
Thanks,
This is easily attainable by using the Identity Trust Framework, also known as Custom Policies.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-trust-frameworks
You can then use a REST API Technical Profile and use conditions within your User Journey that will allow your flow to occur as you have indicated.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/restful-technical-profile
I would also encourage you to review these samples from the Community Github Repo:
Demonstrates using an AAD B2C Extension Property to store an attribute that is then conditionally handled. - https://github.com/azure-ad-b2c/samples/tree/master/policies/force-password-reset-first-logon
Demonstrates how you can use a REST API call during your User Journeys. https://github.com/azure-ad-b2c/samples/tree/master/policies/rest-api-idp
It is worth noting that there are some features coming for API Connectors within the more simplistic User Flows, but I am unable to speak on those.
I've developed a feature on my web-site that allow to log-in using Azure.
So users in my web-site can sign-in using:
Azure (OAuth2). We're using a multi-tenant app. We're just using the application to log in users. So we don't really use the Access-Token to make requests. We just use the access-token to obtain the user email (decoding it with JWT).
Their own email-password they can set on my site.
This creates a problem:
Imagine an person that starts working in a company. The IT team give him an email that belongs to their azure account (with their account domain). This team also have an account on my site (configured with the same domains they use on Azure). So this user will try to log in my site using his credentials. We'll create his profile on their company account (due to the email domain). He sets his password. Sometimes he use Azure to log-in and sometimes he use his email-password to log-in.
The next month and, this person get fired. The IT team delete him from Azure. Although, the IT team forget about deleting him also on my site. So this user has permissions to sign-in with his email-password credentials and still be able to see private information (he can even delete private files).
I would like to know if there is a way to sync my app with every Directory that is using it. So I would be able to receive user action notifications (like user deletions). It would be great to receive a call to an endpoint with information about users important actions. This way we'll be able to delete the user also from our platform. So the company can forget about deleting an user on my site without having the stolen-information problem.
PS: I've seen you have a logout sync using SAML, but I wonder if we would be able to receive other kind of notifications, because we don't want to log-out the user when this logs-out from Azure.
If you have permission from the ex-user tenant administrator to access their directory, you can check if the user is listed or not by using Microsoft Graph API
I've been talking with microsoft support and there is no way of having microsoft calling our endpoint to receive some notifications.
So the only solution is ask for admin permission or, having the refresh_token from Oauth2, check the user still appears on Graph (https://graph.microsoft.com/v1.0/me).
In my third-party web application of Office 365, I want to have access to the contacts, events and emails of all the users from the organizations who installed my app.
The thing is I don't want that all these users have to grant me access, I just want one admin of the org to grant access for my app and then be able to retrieve the data I need for all the users.
To test for one organization, I logged in as the admin and proceed to the Oauth2 authentication to retrieve the access token and in the first request (the GET one to retrieve an authorization code) i add the parameter prompt=admin_consent.
With this access token, I can access the data (emails, contact, event) of the admin
for instance for the contacts
uri: https://outlook.office365.com/ews/odata/Users(adminemail)/Contacts
but not the data of the other users of this org with this uri
uri: https://outlook.office365.com/ews/odata/Users(useremail)/Contacts
The only thing I can do is retrieve an access token for each user but it supposed that each user has to authorize the access to the app but it's very cumbersome.
So, i don't see what enables the parameter prompt=admin_consent and how to use it. Does anybody know what it does?
And my question is: how can I do to access the data of all the users of one organization when the access has been granted by one admin?
Thank you!
Thanks for your question! The scenario you are interested in (an app accessing data of all users of an organization once an admin grants access to the list) is not yet supported but is prioritized high on our list of features to add.
[UPDATE] Support for app accessing data of all users in a tenant is supported for Office 365 Mail, Calendar and Contact REST APIs. Please see Building Daemon or Service Apps with Office 365 Mail, Calendar, and Contacts APIs (OAuth2 client credential flow) for more info.
The scenario prompt=admin_consent is intended for, is different from your scenario. Admin consent simply means that the admin allows this app in the organization without the individual user to see the consent screen after signing on to the app. This special "I as the admin provide consent for this app on behalf of all my users" is triggered by the "prompt=admin_consent" parameter that is passed in during the authorize request. However, this doesn't allow the app to get AccessTokens for any user. Each user still has to get the app, sign in, and the app will hit the authorize endpoint and get a Refresh/AccessToken for the signed in user.
Please let me know if you have any questions or need more info.
Thanks,
Venkat