How do companies like Facebook and Google implement privacy controls at scale? For example, Facebook has a select audience type which includes public,friends, "friends except...", only me, specific friends, and even custom. From an implementation and design standpoint, how do these companies handle this? Are they defining rule bases access controls, are they manually coding in these features, do they have a privacy model they use, or is it a hybrid approach? If anyone has links to public available design docs, conference links, white papers, and even research papers, please feel free to share. Every time I try to search for how company "X" does privacy controls, I get the "Business" talk on privacy or access controls as it relates to data centers which is not what I'm looking for.
In this patent of Google they describe a "User privacy framework" which does all the things you mentioned.
It uses a database which stores rules and privacy levels for each user.
A authorization server manages this database and evaluates requests for user data.
If user A wants to access data of user B, the authorization server checks if the request is allowed or violates rules or privacy levels.
The request is then answered or rejected.
See this flow chart from the patent:
Flow chart (Sorry, I am not allowed to post images yet)
So what are privacy levels and privacy rules?
Rules are conditions which need to be met if a user requests information of another user. I couldn't find an example in the patent, but I suspect a rule could be something like "Is user A blocked by user B?".
Privacy levels seem to be more general than rules. For example the level "semi-public" allows another user to access the requested information if no rule forbids it.
The level "private" allows storage of the information on the authorization server but forbids access of it through other users.
The level "no access" forbids even the storage of the information on the authorization server.
Obviously I have no idea if they really use this on the large-scale. But it is certainly a possible implementation and for me it seems plausible to do it with databases and rule sets.
Hope this helps. Maybe you find even more patents which describe similar frameworks.
Related
I want to release my application in play store and app store.
But, That store require PrivacyPolicyUrI But I don't use signup system
And most application has terms of policy in their signup view
it is essential?
So...
PrivacyPolicy is required for non-signup application, too?
Terms of policy is required even if I'm just developer not company?
Yes, a Privacy Policy is required even for apps that do not require sign-up. However, a sign-up screen is good as you can use the clickwrap method of getting active constent from users to accept your Privacy Policy.
The requirement of a Privacy Policy is due to sensitive permissions you app may ask.
You can find the list of those permissions here: https://play.google.com/about/privacy-security/personal-sensitive/
Even if you don’t need and ask those permissions, make sure you know what third parties you use in the app that might trigger this requirement (eg. AdMob).
You’ll need to add the URL to the Privacy Policy URL at Store Listing section. The link must be publicly accessible. Google will not host it for you.
A Terms of Service is not required, but it’s useful to add rules regarding user-generated content, unacceptable behaviour and so on. For example, it’s useful to add intellectual property clauses, ownership over your content and licenses over user-generated content clauses.
This might be more of an industry question rather than a specifically technical one, but the answer must consider the technical feasibility. I've tried to make the question as pointed as possible. I am working on a new web application that must protect social security numbers, bank account transactions, etc. Security is essential, as is the appearance of security. The company I work for, however, is small. Does it make sense to rely on third-party issuers (e.g., Google, Facebook, Twitter, Yahoo), which are certainly popular but as social media do not convey the seriousness of, say, the banking industry? Or can I realistically expect to implement OAuth/Owin/Katana as securely as these third parties? Is there another option that is both reliable and popular, without being driven by social media? Or does it make the most sense to implement security myself? I do not have a heavy security background, but am willing to learn it if forms authentication makes the most sense for my situation.
Your question is not specific enough to give you concrete advise. But creating your own security is never a good idea.
Whether you should use social media identity providers depends on how much you need to be certain of the user's identity. If the user has to enter all that information him/herself, then you only need to make sure that only that account has access. A social media account will work fine in this case. You can't be sure that the user is who he says he is, but that does not matter as he can only see information he entered himself.
If however this SSO and bank transaction info is coming from another source, you'll need a identity provider that gives you more guarantees about the user's identity (for example the bank's logon server)
I'm working with Azure ACS and incorporating it into an SSO strategy for my .NET 4.0 website. I see on the Rule Groups page that a bunch of different claims can be stored and passed back to the RP (e.g. country, streetaddress, phone, etc.). It looks like you can also return back any claim type you want to create. This got me thinking about many questions relating to storing information for users:
Does it make sense to store user information (other than the nameidentifier) in ACS vs local database tables?
It sounded like you could make unlimited rule groups and rules inside of them. Is that correct?
I would be dealing with different companies and users inside the company. Would creating a rule group for each company and then making rules for each user be a wise choice?
It appears that the API is pretty robust and would enable this to be done automatically as a result of a sign up page, etc. Correct or incorrect?
Would it be feasible and recommended to run a query against ACS to return information back about a user (e.g. query for their email address when they're offline to send them a message about something)
Could you grab bulk information for reporting purposes off of ACS?
The short answer is generally "yes", but of course there's a longer answer :-).
Does it make sense to store user information (other than the nameidentifier) in ACS vs local database tables?
Yes it could make sense. But for optimization purposes you might keep a copy of some of the user profile information somewhere else (local to the app). ACS rules information would be the "master record" you would update the values in your local store whenever you get a token and check whether there've been changes or not.
It sounded like you could make unlimited rule groups and rules inside of them. Is that correct?
No, "unlimited" is a big number. There are limits in the number of namespaces, relying parties and rules. Check the documentation. ACS also supports "cascading" transformations, which can help you reduce the number of rules.
For example:
email: eugeniop#mail.com -> company:Contoso
Company: Contoso -> Language: English
The 2nd rule will be triggered whenever a claim of type "Company", value "Contoso" is issued.
Then you can have:
email: rob#othermail.com -> company: Contoso
The "language" claim will be automatically added.
I would be dealing with different companies and users inside the company. Would creating a rule group for each company and then making rules for each user be a wise choice?
In a multi-tenant environment, it might be better to have a Relying Party per tenant. This is what we do in sample 7 (Federation With Multiple Partners) available here: http://claimsid.codeplex.com
It appears that the API is pretty robust and would enable this to be done automatically as a result of a sign up page, etc. Correct or incorrect?
Yes
Would it be feasible and recommended to run a query against ACS to return information back about a user (e.g. query for their email address when they're offline to send them a message about something)
It is possible. However, there's no concept of "user" in ACS. So yuou would have to decode that from the rules. You can't have a call like "GetUserprofile( string user)"
Could you grab bulk information for reporting purposes off of ACS?
The API supports bulk info, but for reporting it might be better to have replicated information on your own database.
One last thought: ACS rules engine today is very simple and only does simple transformations (plus cascading), but nothing compared to what ADFS can do today, where rules can be really complex (e.g. db lookups, etc)
This is linked to this question which seems to have asked a while back. Security implementation in a project that is adhering to basic principles of Domain driven design. let me give an example
Banking System:
Use Case: A new bank deposit is being made and requires approval as it is first deposit
a. Clerk can auto authorize if the deposit amount is <5000
b. Manager can be of two types - Bank manager / Account Manager. ONLY Account manager can authorize any accounts that have deposit >5000
My concerns are as follows (Pls correct if the concern itself is correct)
Not sure where should i build this following logic - takes care of checking whether the logged on user has authorization to do certain things taking in to account his title - (this case Account manager). Authorizing is a use case, but the security layer seems to have intimate knowledge on the domain object
In general Authorization (not authentication). I know that Role Based authentication would help, but the question is "where" - in which layer and the call flow. Should the UI layer call on some security layer or would the domain layer validate itself for all possible combinations ?
Please help. Its very confusing.
Bump to see if this gets experts notice
Cheers
Security is a cross-cutting design feature which can affect all classes, methods and properties.
From a DDD perspective you would go with specifications and roles.
Where and how those specifications get implemented comes down to your architecture. You could go with aspects, you could go with in-line calls, events, etc.
Here are some links I would check out regarding security and roles:
Security
Roles
RBAC
I am considering adding OpenID to our customer facing admin and control panel areas...
1 - Associating OpenID's With Existing Accounts
For customers that already have accounts with us, I'm thinking they would need to login using their existing account number that we issue and then I'd have a mechanism to associate their OpenID with that account in their account management area (call it 'OpenID Manager' for the sake of argument).
In the 'OpenID Manager', presuming the user already has an OpenID, would I authenticate the user against their OpenID then associate with our generated account number for future OpenID logins (assuming that they authenticated ok)?
2 - Sensitive Data
Although we don't store full credit card data in our DB there is other data that is sensitive, invoices, domain reg details etc. After reading this article http://idcorner.org/2007/08/22/the-problems-with-openid/ I'm a little cautious about the idea of using OpenID in this way, what's the general consensus with you folks?
It seems to me that a lot of the arguments against OpenID are either made out of ignorance or by people with an axe to grind.
For example, the document you link to complains that identifying yourself with a URI is "dehumanising and more than a little frightening". Is that a legitimate complaint, or something written by somebody desperate to find things to complain about?
The two major things that get brought up are phishing and compromised accounts and these arguments have been rehashed so many times, it's hard to take somebody seriously if they bring them up yet again with no new points to make.
Phishing protection depends on the provider. Some providers offer much better security than typical websites ever would. Some providers just offer the typical username and password. Either way, if an account is compromised, that's something between the user and their provider, it's not your concern. You don't worry that the end-user has a keylogger installed on their computer, do you? That's because their local security isn't your responsibility, even though it might be used to gain access to their account. Likewise with OpenID - its security is not your responsibility.
If you compromise an OpenID, it gives you access to more than a single website. Sure, but the same is true for email. Just say you've forgotten your password, and you get sent a new one. You now have access to every account they've registered with that email address.
OpenID is no worse than the status quo, and it's significantly better in many circumstances, especially for informed users. If you are still wary of it, then just make it optional, so only the informed users use it.
I'd allow the registration of multiple OpenIDs with a particular account. That's a nice feature to have because it allows users to migrate between OpenIDs should the need ever arise.
That said, the idcorner link raises a good point. I think he massively overblows the security issue and makes many idiotic assumptions about how OpenID providers work, but that OpenID really isn't intended to replace all forms of user authentication. It's designed to make it easy for "drive-by" users to interact with a site with some form of basic authentication.
Ever been to somebody's blog, want to post a comment, but first you have to step through a 3-page registration? OpenID solves that problem.
Want to post a quick bug report on a public tracker but need an account first? OpenID to the rescue.
Want to store sensitive proprietary data in a web-accessible way and provide access only to people who are trusted? OpenID is not the solution.