The project I'm working on is a set of tools for users to manage their own accounts. For example, generic users will be able to access and update their Drive or calendars, and for administrators they can additionally get lists of their users and groups and manage those.
My concern is the API limits. At this point in time the project's client ID and secret are hard-coded because I want users to just be able to download and run the tools (which is working great until someone queries all users and uses up half of the daily limit for one of the APIs). I realize I can request more API calls, but I'm not sure that's the best solution.
In order to have each user on their own API limits, will I need to have each person using it set up a new Google Code project with its own set of limits? Or is there a way to allow the same project to have limits based on domain? I'm not sure what best practice is.
Edit: I should mention I'm authenticating via OAuth2.0 using 2-legged authentication, as my understanding was that was the best way to do it for administrators and users... should I be using 3-legged instead?
This is (probably) not an answer, but ...
A good question is precisely what is an "app". In this answer What is the limit on Google Drive API usage?, Nivco from Google says "Currently for the Drive API it reads "Courtesy limit: 10,000,000 queries/day". It's a per app quota"
and on the API Console, your project can consist of many "apps", each with its own client ID.
So, either (a) the term "app", being ill-defined, is being used incorrectly, or (b) you can achieve what you are looking for by creating multiple apps within your project.
Sadly, I suspect it's (a), but might be worth confirming.
Related
The requirements
we have 3 modules ui, api, IdentityServer (IS) (client, resource, IS in terms of IdentityServer)
all the modules should be separated from each other (separate dbs for IS and api)
api is stateless (all the needed auth info got from tokens)
the api will have resources like \projects, \users, etc.
another entry point may be added in the future like another-ui which will communicate with the IS and api and will have its own claims
The problems
The main problem is that the resources of api like \projects\12345, \users\, \projects\123456\users, etc. may also be needed as claims in IS. For example, api module reads the access token of authorized user and see the claim projects that equals ["222", "12345"], so the resource \projects\12345 or \projects\123456\users are allowed for that user.
Users are identities in IS and resources in api at the same time. Projects are claims in IS and resources in api at the same time.
I thought of book-keeping these entities that are represented in both modules through the ids (guids). But ids won`t solve all the problems.
Some of them are:
creation of a new project with its id should grant that user the rights to use it in the future, so we need save the claim for that user in some way. The modules are separated, so should we call the IS api to create that claim for that user and then proceed with project creation. How the communication between the two (IS and api) should be organized? Do we need to register the api as another client in IS?
How should updates of users in IS like changing the email, phone (the values one may log in with) will update the api. I thought of showing warnings that the auth email (got from token) does not match the info email.
Could you, please, explain how modern systems coupe with the per resource access?
Thank you for your time.
First you need to make sure what a claim is.
Claim is not a permission or a role, it's what the user is. Based on what the user is, then you can assume the permissions.
https://learn.microsoft.com/en-us/aspnet/core/security/authorization/claims?view=aspnetcore-3.0
A claim is a name value pair that represents what the subject is, not what the subject can do.
So starting from that, you can get the claims and do the following.
Let's say that a user is the owner of a project. When the new project is created, the project api can update the identity server and add a claim to the user saying he is the owner.
In your apis the owner of a project has a set of permissions and based in those, access to specific resources
In the DDD Domain driven design world, a little bit of data duplication does not matter. So duplicating the possible claims that your application needs in terms of roles (again, not ids but a mapping of one or more claims to specific roles) is not a bad practice.
When you update some kind of claim from your api, you should do so in a transactional way. Think first if you need the email to be saved in both. You will get the user data from the claims anyway on every request. Is it even something you need as a claim? If not have it in your api only.
Communication between apis is organized in many ways. If you need transactions or eventual consistency is something you should also consider. Communicating with events or queues is the microservices way to go, with patterns like the SAGA being the coordinator.
I'm trying to find a solution to handle authentication on my new application, and I like the approach of IdentityServer3. I would like to hope my requirements are met by IdentityServer3 and it's just my lack of understanding due to my newness with the technology.
My requirements are as follows, and in order of desired execution:
1) If a user requesting authentication is a local (domain) user, they should be authenticated automatically using Active Directory.
2) If a user requesting authentication is not found in Active Directory, they should be authenticated against our own User table.
3) If a user requesting authentication is in neither Authority, we may choose to grant access via Google or Facebook credentials, but that's not a Phase I requirement.
I currently have a working proof of concept using IdentityServer3 as a standalone security server pulling records from the InMemoryUsers, InMemoryClients and InMemoryScopes, and I'm fairly sure I'll be able to expand on those concepts for pulling from our own database.
This problem comes when I try to use Active Directory as the first checkpoint.
I've looked at a couple of resources in an effort to accomplish the Active Directory, but I'm getting all tripped up as I'm not seeing any concise demo that shows the AD piece of the puzzle.
TJ Robinson has a Gist of an ActiveDirectoryUserService that implements IUserService, and that looks to be the most promising, but because of my n00b status, I can't seem to figure out how to roll it into the scheme.
I would really appreciate any suggestions, and, perhaps, links to examples of how to do AD authentication first with a fallback to local authentication.
Thanks in advance,
Ric
In regard to your first requirement...
I believe you should examine the Windows Authentication Service. This is essentially a mini security-token-service that can work as an external identity provider to IdentityServer to provide Windows Authentication (over the WS-Fed protocol).
If you follow that link to the GitHub page, you will find two links to samples that can you get started with this component. One sample has both Identity Server and the Windows Authentication Service hosted separately and the other sample has them hosted together.
A separate option could be to use ADFS (if you have one) as an external identity provider.
Those samples include a custom user service (ExternalRegistrationUserService) that shows those windows users being mapped to an in-memory collection of users (in Identity Server). Your requirements will obviously demand a different implementation of that user service, but I hope this might help get your started with the Windows Auth part.
When I went through this exercise recently, I found a lot of good information in the closed IdentityServer3 issues (for windows auth). Lots of good info on Stack Overflow as well; good luck!
We have a developer debugging tool to help manipulate security section of a database that our product depends on. This tool's purpose is to inject state into database to reduce time to create test scenarios. The database is not typical database that one can manipulate using sql. Rather it is a binary file that only our tool can manipulate. This is a C# application.
If this tool goes outside our company (say someone emailed it to a customer who shared it somewhere public), that could open lot of security issues.
We like to build intelligence into this tool so that it is usable within company or at partners network with whom we shared the tool. We have no knowledge of partner's network.
I am wondering what the suggested ways of implementing it?
Like:
Ping company active directory server or exchange server. Allow the tool usage if you can reach one of these servers.
Package a certificate with the tool that expires a month from build date. Always check if the cert expired or not before allowing usage of the tool.
Modification of (2). Make every user to request a key to unlock the tool after specific date.
Before we go implement a solution, I am wondering if there is already a library that does this.
Thanks
Assuming you host "file" inside your organization and all parties just access it somehow. If you give both data and tools to modify it to external partners there is nothing really to stop them to modify data as they pleased (short of legal/administrative actions but that is outside of SO scope).
There is also really not much you can do to protect code running on user's machine irrespective if it is C# or native compiled code. .Net code is a bit easier to modify/bypass protections but if you concerned about securing access to a file you need to protect files/servers rather than worry about client side code.
Usual solution to such problem - authentication and authorization: only allow authenticated users to access the file and only accept changes from authorized users.
If you use file based storage than inside your organization regular Windows domain accounts would work for authentication and regular file system permissions would work for authorization.
For outside partners you probably would need server to perform modification of the file(s) and authentication/authorization possibly using ADFS or Oauth.
I am working with an asp.net application in .net 4.0. I have configured it to use windows integrated authentication.
What I want it to do is use the user groups on my pc/server as if they were roles. I can't find documentation or mention of it anywhere from my google results.
The reason this is required is because we have a COTS product which does this and we want to reuse the groups as roles.
Could I get an example or a pointer to some documentation so I can figure out how to do it?
The end result here was that we communicated with our Sever Services team who were more than happy to help us use Active Directory to come up with a Corporate solution instead of using individual server user stores. This is a much better solution as the groups are reusable and integrate with other applications too.
The lesson here is that engagement with IT services with a business case is always worth the effort.
I'm writing a set of Powershell Cmdlets that allow a user to run admin functions on their domain. Using gData I have been able to do provisioning calls to create new users, list groups and other things of that nature. When trying to list another user's documents (as admin) I hit a roadblock with the DocsList api, so I turned to the Google Drive api instead.
I've since been able to get the Drive API working and have a Cmdlet running based on their QuickStart for DotNet and File List Example. However, I can't seem to figure out how to make it list docs for another user. Everything I've found so far seems to point to the use of Service Accounts for delegation or using the old DocList api instead which is depreciated in favor of the Drive API anyways.
My problem is the Service Accounts seem to be an alternative to the Installed Application, not something I can use at the same time. Or, if I were able to get it working I would have to have each user create their own project and service account, if I'm understanding things.
How can I do this without inconveniencing the users? They've already authenticated themselves as admins, I don't understand why they have to create an API project and service account to achieve the same thing. Would I create a single service account for my API Project? If so, how do I handle the public key it generates and needs access to? That doesn't seem very safe if I'm throwing around the key file.
You can impersonate a user only with service accounts. Once you configure your service account for domain-wide authority, you can make requests with your administrator account as you mention. But, I'm not sure Google Apps allow multiple administrator accounts or not. If they do, all you need is setup a single project and a single service account.