I have been working on a server to server google calendar integration, where by it connects, reads and writes to a user's calendar.
This is working perfectly fine, however I have a question regarding permission scope. Using a service account with domain wide delegation, it means that this account has access to calendars for every single users in the organisation from the CEO to me...
Is there a way of limiting this scope from Google's side, so that the service account can only access specific accounts, similarly to how EWS allows delegation rules.
One idea I had was to create a separate organisational unit and create the project under that (not tested this theory, but it also doesn't feel very scaleable).
Any ideas?
Thanks
The service account only has access to whatever is shared with the account, as per Delegating domain-wide authority to the service account:
an administrator of the G Suite domain can authorize an application to access user data on behalf of users in the G Suite domain
This means that the service account only has access to data from the account the application is impersonating.
In your case, using Org Units would not fulfill your requirements.
These controls have to be implemented on the application level. AKA by you.
One of the ways you could do this is, before impersonating any account, use the service account to query which Org Unit that account belongs to, and then based on that allow or deny the impersonation.
Of course, you can also do this type of filtering in multiple ways. You could simply check if the account you wish to impersonate is on a blacklist and abort the impersonation if that's the case, or you could use other criteria.
Hope this helps!
First and foremost: A service account is technically a superadministrator once DWD (domain wide delegation) is enabled and the client ID authorized by any admin in the Admin Console.
That translates to: a service account can impersonate any user including any administrator and performing any action allowed by the declared scopes.
In this case: A service account with allowed scope https://www.googleapis.com/auth/calendar.readonly can read any domains calendar.
Now there's a somewhat nasty workaround:
A service account is basically a gmail account without access to the web UI. So you can indeed share a calendar with a service account if and only if external calendar sharing is enabled. Then you do not use DWD. In this case the service account can only act as the sharing permissions dictate. However this is not how a service account is supposed to be used.
Related
I'd like to restrict certain requests to whitelisted IPs.
The implementation seems easy enough; just store the user's IP as a custom claim
that can be checked against a whitelist using security rules.
How secure is a Firebase app layer firewall based on auth token claims?
Alternatively, should the problem be tackled by restricting access to certain oauth providers (Azure AD, Auth0) that provide conditional access controls such as IP and device whitelisting?
References
Context Object Properties in Rules
Conditional Access: Grant
Control Access with Custom Claims and Security Rules
Posting Frank's comment as Wiki for visibility.
Custom claims can only be set by users with administrator-level access to the Firebase project. So if a certain claim is set to a value, you can be certain it was set by an account with those access permissions. But it's hard to say more about how secure an implementation is going to be, because that depends almost solely on the implementation.
According to the docs, Google Apps domain administrators can grant service accounts domain-wide authority to access user data on behalf of users in the domain. My understating is this gives service account authority to access data for all users inside the domain. Is there a way to restrict which users service account has access to? If yes, how? Additionally, is there a way to create a "Project" within an existing Organization Unit so that I can move users within that project and then within a service account so that only a list of email accounts that are placed in it.
For example, an application that uses Gmail API and Google Calendar API to view events from the email and calendars of specific list of users in a Google Apps domain.
Can google apps administrator authorize application for access to some but not all users?
We have a hosted .NET web application (Windows Server 2012 R2 environment) and we need to provide Single sign-on (SSO) to users from a corporate LAN environment. We have used ADFS to enable SSO and it is working as expected thus when a user hits our web application login page URL he is authenticated against ADFS and is automatically logged in to the application.
We have an additional requirement where we need to obtain a list of all users, their groups, email addresses some additional information periodically from their Active Directory so that this information can be bulk loaded into our web application however since ADFS is implemented we do not have direct access to the Active Directory.
Is it possible to connect to ADFS and obtain a list of all users, their email addresses etc. programmatically?
If the above is not possible then what is the recommended approach for this kind of a setup?
Thank you.
No, this is not possible. There is no such API because with SAML and WS-Federation, users can come from anywhere. This does not have to be AD, technically it's possible create a "Log in with Facebook" implementation.
What would you need the information for? The user's claims contain all information which you might need (user name, e-mail address, group memberships).
If you really need that information about all users in your application, perhaps ADFS is not the solution you are looking for.
As Alex mentioned above - the way it works, ADFS does not provide any way of importing data from the AD or other trust stores. It just gives you the information that are carried over with the token.
In case you need more information, you should extend the number of claims being issued by ADFS. You can then collect the information - when the user comes for the first time, use the data from the token and fill the profile. If it is returning user - update the information if necessary.
The other solution (but I wouldn't say it's recommended - rather a workaround) would be to implement custom solution for importing information from AD to your application. I'd say it's fair as long as you use your local AD for reading this data. In the moment you decide to extend the access to third party (e.g. partner company), which might be using different identity provider, which doesn't have to be backed by Active Directory any more - you find yourself in tough spot.
I am new to Identity server but I found it quite easy to set up.
Our goal is to implement SSO down the line but at the moment we are just moving our authentication logic out of application.
It is going good except I have one confusion.
When I set up the Idsrv, I had to create admin user as well as token requesting user. This was to access and configure Idsrv.
For application auth, I have to use Idsrv as federation server as well and authenticate users against some Asp.Net data store.
Now there is already one data store where Identity server specific users are stored.
Should I be using same store for my application user auth and created/edit these users in that store? Or can I/should I create a separate database for application specific users and use both?
At the minute, I am authenticating application users against Idsrv store.
I am not sure if I am logically thinking in right way to split these two user sets and calling one as Idsrv specific users. (We will have Identity service separately deployed for each application)
Thanks for your help in advance.
"Authentication requests to Firebase Simple Login are only permitted from domains you specify." and the two default domains are "localhost" and "127.0.0.1".
Let's say that my server's IP is "267.156.423.22". How do I setup my security rules so that that the two first domains can read specific data, but only the server can write it?
For example, if a client purchases a product, this fact and associated data needs to be noted on the client's account in the Firebase. For obvious security reasons this information must be 'writeable' by the server only.
The authorized domains configuration for Firebase Simple Login applies solely to OAuth-based authentication providers (Facebook, Twitter, and GitHub), and restricts requests to those origins in the browser.
That means if you're using one of those OAuth-based authentication providers, you'd want to enter in any origins which your end users will use to access the page (i.e. if your user accesses the page via subdomain.example.com, that'd the be origin to enter).
Keep in mind that Firebase Simple Login is built on top of that standard, one-size-fits-all custom login / token generation in Firebase. It is an abstraction layer intended to make it easy to generate Firebase Auth. Tokens, a secure way of sharing data between you and Firebase.
Once a token has been generated (via Simple or Custom login), you can begin using that token's payload in your security rules (via the auth variable). If you'd want your server to bypass security rules, simple generate a token with the admin privilege, or your Firebase secret. See https://www.firebase.com/docs/security/security-rules.html for more details.