The integration between OIM and Microsoft Exchange is in place. Now we want to provision lync or skype for business to this user. What are the possible ways to do it? Also is it necessary to have O365 email id for every user whom we want to grant skype for business access?
My research says :
Create custom O365 connector and use Graph APIs to perform user life cycle operations like provisioning deprovisioning.
Use Exchange connector and create a process task that will call some API to create skype account.
The approach we choose to solve this problem is we created Skype Enabled user group in AD , and assigning the users to this AD group if they have skype enabled flag true in the user profile.
At Active directory end Admin guys are managing the provisioning of Skype for Business Account.
Related
I'm planning on building a G suite integration with my existing SaaS site.
I want Gsuite admins to allow access for their organisation. So I only want "domain install" possible.
After this has been done users can be imported from Google into our application. Users should be able to use SSO to login but I don't want each user having to pass the consent screen.
I also want the app to have readonly access to the calendar of the user.
What is confusing for me: do I need to create a regular web app integration or a Service account integration? I don't really need offline access but I want to avoid all users having to grant access individually.
Here it says: The user sees the OAuth Consent screen only once; if you’re using a service account to allow a domain admin accept terms on behalf of the domain users, then the end users must never see the OAuth consent screen.
So does that mean only service accounts allow this?
Yes, using a service account you can install and authorize one app for all your domain user impersonating the admin account. In such a way, your users won't have to authorize the app individually.
You will have to enable domain wide delegation in order to impersonate the admin account when using a service account.
Reference
Service Account
Is a Service Account intended to be created in an application’s domain? Or in a clients G Suite Domain, on behalf of the application?
Background:
My company has a product (hereafter “The App”) which has several thousand organizations as clients, each potentially having their own Google domains. (hereafter “Organization Domain”)
We are looking to set up a sync between The App and the Organization Domain, for data that is common between The App and the Organization Domain, and want to use an OAuth2 connection, with a domain admin granting The App ‘domain-wide authority’ on behalf of their users, for offline syncing.
From the Service Account page:
... an account that belongs to your application instead of to an
individual end user. Your application calls Google APIs on behalf of
the service account, so users aren't directly involved.
and
G Suite domain administrators can also grant service accounts
domain-wide authority to access user data on behalf of users in the
domain.
Referencing the Cloud Platform Console Help Faq:
You can access data from your users' Google Cloud Platform projects by
creating a service account to represent your service, and then having
your customers grant that service account appropriate access to their
cloud data using IAM policies. Note that you might want to create a
service account per customer... (emphasis added)
It sounds like The App should be able to create a single Service Account, which all of our clients authenticate into for their Organization Domain.
The part that’s unclear:
In the Service Account page, the instructions for delegating domain wide authority seems to shift concerning where the Service Account is.
Before the instructions, it reads:
... first enable domain-wide delegation for an existing service
account in the Service accounts page ... with domain-wide delegation
enabled. Then, an administrator of the G Suite domain must complete
the following steps:
Afterwards, it reads
Your application now has the authority to make API calls as users in
your domain (to "impersonate" users). (emphasis added)
From what I’m reading, the first part reads "one Service Account for The App", while the later reads as "the service account is only able to access as a person on The App domain, rather than the Organization Domain."
Is a service account intended to be created in The App's domain? Or in the Organization Domain, on behalf of The App?
I have seen examples that have the Organization Domain admin create a service account, and then pass over the clientID/secret to the owners of The App… but I’m not sure that’s the correct approach for our scenario.
Related - Scope management:
The delegation steps have the Organization Domain admin manually add scopes.
We’d prefer to use the OAuth consent screen, which shows the scopes, and has our pages/policies linked.
Unfortunately, as far as my research has uncovered, it doesn’t look like that page is used in the Service Account authorization flow; just for other application types, which authenticate a single user, as opposed to an entire Organization Domain.
Is there a page I’ve missed in Google’s sea of documentation?
I think you are miss understanding the use of Service accounts.
Service accounts are dummy user accounts. They have their own drive account, calendar account and probably a few more. Service accounts are designed for use with back end applications server to server communication where there is no user interaction. Service accounts are preauthorized. You grant the service account access to the user data in your case by using domain wide dedication to the gsuite account. This way the service account would be able to for example send control all the users google calendar accounts.
This is why you dont need a consent screen. Another point with service accounts is you must control the data in order to set this up. If you dont control the data then you cant grant the service account access to that data.
You should be using Oauth2 if you want to access private user data owned by your customers.
As for the rest of your question is very broad and i am not really user where to start with it you might want to break it up into several questions. Take them one at a time. I am not sure i understand what it is you are trying to do so i dont think i can try to answer that part.
Microsoft Graph uses application permissions for background services. For Outlook APIs, application permission Mail.ReadWrite grants access to all mailboxes.
Is there a way to restrict access to a particular mailbox?
https://developer.microsoft.com/en-us/graph/docs/concepts/permissions_reference
No you should use delegate access in that instance and the Mail.ReadWrite.Shared grant which will give access the Mailbox of the Owner and any of the Mailboxes Shared with that users (eg they have been delegated access to).
I agree what your talking about would be a nice feature being able to opt out of Application permissions for certain mailboxes/users etc is a requirement that comes up but the ability to do so doesn't exist. One way to mitigate that is with logic on the server side eg force the application to check a group before accessing Mailboxes etc and make sure auditing is switch on so you can catch any malicious use of the tokens and credentials.
Graph authentication through Client Credentials flow - Will my app have access to just my user account or to the whole organization?
https://github.com/microsoftgraph/microsoft-graph-docs/blob/master/concepts/auth_v2_user.md
This is now possible according to Microsoft Docs.
Some apps call Microsoft Graph using their own identity and not on
behalf of a user. These are usually background services or daemon apps
that run on a server without the presence of a signed-in user. These
apps make use of OAuth 2.0 client credentials grant flow to
authenticate and are configured with application permissions, which
enable such apps to access all mailboxes in a organization on Exchange
Online. For example, the Mail.Read application permission allows apps
to read mail in all mailboxes without a signed-in user.
Administrators who want to limit the app access to a specific set of
mailboxes can use the New-ApplicationAccessPolicy PowerShell cmdlet to
configure access control.
I have a desktop application which I want to create a new service account for each user of my application.
Is there any API for creating the service account users on the fly?
Scenario: For each user, I want to give service account, and give this service account the data that this user needs.
The point is that I want to give every user some specific data from Google Cloud, but I want the user to get it directly from Google. I cannot use the user account, because I am not sure he have google account.
You can use the Google Identity and Access Management (IAM) API to programatically create service accounts.
However, creating a service account for each of your application's users is expensive and not scalable. Perhaps your service can have a single service account and then the service can control which of the resources that the user may access.
There is no Google Api that allows you to control projects on Google Developer console. The only thing that comes close is the Google Cloud Resource Manager API which is extremely limited in what it supports. You cant use it to create a service account.
Answer: The only way to create a new service account is to log in and do it though the Google Developers console.
We've been working with EWS Managed services for a while now, however we would like to transition over to using the RESTful API for Office 365.
Is it possible for an application to access all of our users data without their consent? We have an in-house application that we would like to get some O365/Sharepoint data to our users. Using SSO isn't really an option, as we don't want to keep asking our users to give consent (we assume they already give it). Specifically, we want access to calendars and mail.
Are these "service/application level" accounts available in O365 yet? I think I read a while ago that they are on the roadmap but I have not seen anything since.
Would it be best for us to continue using impersonation with EWS for now until it is ready? (For some reason, EWS is painfully slow when getting data, meanwhile our tests with O365 SSO are a great deal faster, but we do not want SSO).
Apologies if this does not meet the requirements for SA questions. Thanks.
EDIT. Daemon and Service Apps are now possible with Office365. Check out this link.
Building Daemon or Service Apps with Office 365 Mail, Calendar, and Contacts APIs (OAuth2 client credential flow)
App-level authentication is coming soon. Basically an organization administrator will have to consent to allow the application access to mailboxes in their organization, then you'll be able to authenticate as the app, rather than acting on individual users' behalf.
I'd say keep working on your prototype using the user consent model that's in place now, and keep an eye on our blog or my Twitter account (#JasonJohMSFT) for the announcement for app-level auth.