Do you need to obtain explicit affirmative user consent to send their data to a third party?
Currently we have a form on our website for users to fill out to register interest in our service. This data is then stored in our own database, but it is also sent to a sales service provider and a marketing service provider.
Do we need to get explicit consent from the user to send their details (personally identifiable, includes name and phone number) to these third party services?
Because the user has willingly given us this information is it OK to just send the data to third parties or do we need consent?
Is the third party acting on behalf of you and your core product which the customer has shown explicit consent in being contacted regarding?
If the third party is a Data Provider and handling the customer's details on your behalf, to provide a service that the customer has explicitly consented to, then my understanding is you will be ok.
If they aren't providing a service that the customer has consented to receive information on, or they are selling an unrelated service or product, you're going to be in big trouble.
Basically you are the Data Controller: you have procured the information directly from the client and it is all necessary to fulfill the task for which it is given, and any contact will only receive communication relating to it or that they expect. If you or the Data Provider breach this then you, the Data Controller, could be in trouble.
I know the topic is a bit old but, it is becoming more and more relevant due heavy fines now been issued throughout EU.
GDPR/CCPA is making a lot of people nervous, no doubt. I think most website owners have no clue about cookies or what it is used for. Due the inconsequential use of cookies (thus far), cookies were never subject of discussion.
My best advice is, before getting worked out over fines and implications, to get familiar with GDPR/CCPA regulations. Most importantly, before implementing a 3rd party tool, check if your website really needs it. There are not many free online tools which allows you to check your GDPR compliance status but, sites like https://www.gdpr-service.com/consult allows you to verify if you really need a major change in your website.
If you have 5 to 10 cookies containing no 3rd party, you might as well contract a programmer to build a popup acceptance module for you. Else, I'm afraid you will need to signup for some service which provides you with the cookie policy (including cookies group and description) in order to be compliant.
Related
I am developing an ASP.NET Core web application with user management functionalities. My question is about the email address changing algorithm. Almost every web app I saw before have the following flow:
User authorized
User requested an email address change
User received a message on the new mailbox with the confirmation link
User clicks the link and the email address updates
But I think, this algorithm might be a bit insecure and that is what I want to discuss here.
How about this flow:
User authorized
User requested an email address change
User received a message on the old mailbox with the confirmation link
User received a message on the new mailbox with the second confirmation link
User clicks the link and the email address updates
With this additional step in the middle of the algorithm, things may be much better from the security perspective, but would it be too complex or not? How do you think what algorithm I should implement? And what would you prefer if you will be in my shoes?
The second options might sound great, and it's not too much headache to implement too. But I'll stick with the first approach due to some reason:
Common work flow pattern.
As the backend side can be wrote by many language, by various developers, so common pattern would make things more standard when we need some kind of migration, and even maintaining by new developer. If the project doesn't require ultra-secure authentication flow, the simplicity of first approach was enough.
From user convinient pespertive
Let's just imagine when changing an email address, what case the user likely want to change email address ? I was register my facebook account long ago using yahoo mail, that's no-longer active, and i need to switch to a gmail one. What's the point of sending the email back to the old one ? Cumbersome... and i can do nothing in this case except get some help from the staff.
I totally aggree with the second approach on security angle. But that's not suitable for most of the case, only implement if the project have some requirement. And even in that case, I suggest don't even do that too, build some thing like sub-admin account role and grant permission to someone have responsible. Like Google enterprise email organize some account called admin if anything wrong happen to user account. As long as it has this kind of security level requirement, it's not gonna serve massively user.
The intension of all the flow
The User got authorized first, right, that's mean we Identified what the user are, and what she capable to do. Imagine when we hide a hotel room then request to change to another due to some reason. What's the point of proving that's I booked my own room, since we all know that's the fact ? Kinda weird... right ?
To conclusion, I think we shouldn't mess with something that's become common pattern that widely acknowledged, except we have some special requirements and the project have something uniquely to satisfy, and we consider ourself, as developer that's reasonable.
The main problem with this approach is: what happens if the user no longer has access to their original email account? Perhaps it was a work/school/uni account that they no longer have, or perhaps they've just forgotten their password or otherwise lost access to it.
With your second approach, they are not going to be able to update to the new account, because they'll never receive the first confirmation link.
How about the following approach instead:
User requests an email change.
Require the user to re-authenticate with their current password (just like when they change their password).
Send a confirmation link to their new email.
Send a notification to their old email, with the details of the change, and instructions of what to do if they didn't initiate the change.
User clicks the link to update or contacts your support to say their account has been compromised.
This way you still provide them with an alert that someone is trying to change their email (and potentially a means to stop it), but a user who has lost access to their old account will still be able to update their email.
I need to have access to Calendar information from a company's G Suite accounts, to synchronize data with the company system through a API.
When I need to provide access to my own data, there is a fairly simple way to do it. Using Oauth2, through a login window the user allows the API to access the requested data.
But in the G Suite documentation, the path indicated when involving the administrator and company data, involves the administrator accessing admin.google.com, go to the security-related session, and manually register my API, listing the scopes that he wants to grant me access.
To make a parallel, in Microsoft Graph there is a way to request consent from the domain administrator, where only a user consent / admin consent screen is displayed using Oauth2.
I wonder if there is a way to get this type of access in G Suite without requiring the end user to take such complicated steps to make my API work properly.
UPDATE:
This question was originally posted in 2019, does anyone aware if something was changes since then?
You should use the Marketplace SDK for this. This allows you to publish an application to the Google Workspace Marketplace where company admins can choose to install it for their domain.
There are a couple things to keep in mind:
There's an expectation that your application will have some sort of user facing presence (e.g. add-on, link to web app, etc).
Google will review your app before publishing. Since you're not using Gmail or Drive scopes (for these, Google requires a 3rd party security review), this process should not be too difficult. But plan for it to take some time, and follow the best practices so it's done right the first time.
You also mentioned synchronizing calendars. If that means mainly reading, no problem, but if you're writing (a lot at once), be mindful of calendar use limits. These are per user and for all activity by that user (not just your app).
I am working on designing an approval system in CRM and need some inputs on the security design. The entity I am using has User/Team level R/W rights. The overall implementation is bit complex but to keep this question simple, consider the following two parties involved in the system:
Requester: Needs R/W access on requests created by him.
Approver Team: These are pre-defined teams whose users will approve/reject the request. Needs R/W access on requests which need their approval.
Question:
How can I handle providing R/W access for both - Requester and Approver Team at the same time? Since we can't have multiple owners of a record in CRM, the Owner field can only contain either of them (Requester or Approver Team) at one time.
I can think of two solutions to this using sharing functionality and wanted to confirm my understanding:
a. Set Requester as the record Owner and share the record with Approver Team programmatically. The problem with this approach is that even if I share the record with Approver Team, I won't be able to show the sharing details on the main form (which is a requirement).
b. Set Approver Team as the record Owner and programmatically share the record with Requester using Access Templates.
Is there any better solution to handle this requirement, in case I am missing any OOB possibilities?
Well I believe that you can make solution A working with a little bit of coding (I'm not sure if you don't mind coding, but we are on StackOverflow, so I think you should consider that).
First of all the design depends on the simple question - should this Request be shared with multiple teams, or only single team? Single team is simple - just add a lookup on the Request, that will point to a Team. When this team is filled in (I'm assuming that choice of this team is done somehow automatically, but it does not matter as in any scenario you would have to choose the team anyway somehow), you run a simple plugin that shares the record for this team. Sharing using SDK is really simple, just use the GrantAccessRequest:
var grantAccessRequest = new GrantAccessRequest
{
PrincipalAccess = new PrincipalAccess
{
AccessMask = AccessRights.ReadAccess | AccessRights.WriteAccess,
Principal = teamEntityReference
},
Target = requestReference
};
So on the form of the request you will keep the owner of the Request and will have a lookup pointing to a Team that is handling this request. Of course you can further pimp it up by for example un-sharing when the request is accepted or declined or the lookup on the request is changed etc. That would keep the POA table more happy as sharing huge amount of records can lead to fast grow of that table, so it's important to unshare records if sharing no longer needed.
If you want to share to multiple teams, you can still create a N:N relationship between your Request and Team and simply share your Request in a plugin on Associate message between Request and Team (this was a standard option before Access Teams were introduced for the users, remains still the only option for teams). This relationship can be show as a subgrid on Request form (it would look like an access team subgrid).
Of course to prevent users from Sharing the Request record on their own (in that case you will not have the Team in your lookup/subgrid) they should not have Sharing privilege. The plugin should do the sharing in admin context.
UPDATE:
As for the POA considerations from the comments: both solutions will make your POA grow, because for both solutions you will have to share the Request either with the team or with the user. If you will use access team you will still have one POA entry for each Request (so 100K entries per year). I believe that the most important thing here is what happens with the Request when it ends it's lifecycle. If it does not have to be visible to the Team, after it was accepted/rejected then you should simply have a mechanism (plugin or some custom app running on some timely manner) that would unshare all the Requests that no longer require sharing, keeping your POA table in reasonable size.
There is another way of handling your scenario that would not require that much sharing/unsharing logic. You can create a "Request Acceptation" entity in 1:N parental relationship with Request. Because it's parental relationship, user owning Request will see all the "Request Acceptation" and "Request Acceptation" will be owned by proper Team (so only this team will have access). Of course I don't know anything about the business logic, but I assume that "Request Acceptation" can contain only the information relevant to the Team which can be copied in a plugin or workflow.
UPDATE2: As I just saw that you cannot unshare the record at a later stage. But I'm assuming that at some point of time Request is done/accepted/finished/rejected or whatever. If at this point both Teams and User should have access to this Request, then maybe it's a good thing to create some kind of separate entity "Archived Requests", that would not be shared, simply cloned for all the principals that are interested in seeing this information and deleting original Request. There are many variations of this idea, I hope that you get it and can adapt it accordingly to your scenario
Your option a makes the most sense: Requester being the creator, should own the Request. Approver just acts on the Request, so it should be shared with.
About showing sharing details, you can put a subgrid in the form: https://www.microsoft.com/en-us/dynamics/crm-customer-center/create-a-team-template-and-add-to-an-entity-form.aspx
Add a team template to the entity form
Make sure you have the System Administrator security role or
equivalent permissions in Microsoft Dynamics 365.
Check your security role
[read more in the linked page]
Since Requester is a USER an Approver is a TEAM, OOB you can only do option b (assign to the team, share with the user via Access Team).
I can't think of any clean solution involving enumerating the team members and act on each of them, so I won't suggest it.
I am trying to build a small toolbox of scripts such that I can automate some tasks involving Google contacts, calendar and so on. Most of the work is already done by means of the googlecl project, which looks very promising.
As far as I understand the process, googlecl needs to request an authentication ticket from Google by means of OAuth. Admittedly, I have only a sketchy notion of what is going on there, but that’s something that Wikipedia will help me solve.
Here’s the catch: My Google account uses a non-Gmail address (let it be vucar#example.invalid for the sake of this discussion). The account was created back in the old days when Google didn’t force GMail down people’s throats who have no use for it. googlecl will direct me to https://www.google.com/accounts/OAuthAuthorizeToken?oauth_token=…&hd=example.invalid to complete the OAuth handshake. Google will then tell me that ‘the domain name has not been signed up for Google Apps’. Which is correct.
If I don’t supply my user ID to googlecl, then the URL reads …&hd=default. Google will accept the OAuth request, granting whichever permissions needed to my locally running googlecl, but then googlecl will complain that the token was issued to a different user ID than for the user ID that was requested. Which of course is also correct.
I’ve read through https://support.google.com/a/answer/33419, which in turn redirects me to http://www.google.com/a in order to ‘to sign up your domain for Google Apps’. Apparently, if my Google account uses a domain different from #gmail.com, then I am a business user and need to purchase Google Apps for my domain—to get, amonst a truckload of other stuff, my domain connected to GMail, the polar opposite of what I wanted to have by having that ‘foreign’ domain in the first place.
I have to admit that I am stymied. I understand what OAuth in this case is used for, but I fail to grasp the byzantine reasoning at Google’s. I do not believe that I want Google Apps for my domain, and I especially do not want to hand over my emails or anything else to Google. I merely want to access and modify my data at Google’s, with my user ID happening not to end in #gmail.com.
Is it strictly required that I purchase Google Apps for Work for such a configuration? The contacts, calendars and so forth is already at Google’s, and used from both Google’s web site and Android clients. The only thing new to the mix is API access.
I'm a little new to this and please bear with me if I ask dumb questions.
As what I know, session is something saved at server (either in file or in database), and client access it via sessionid saved in cookie. To keep user login information, we can simply put a 'logged_in' column and an 'expired' column in session file or session table.
As far as I know, Oauth2.0 is designed for third party client to access the server. The whole process is controlled by an access_token, which is quite similar to sessionid (at least from my knowledge).
So, here's my question, is it possible to use Oauth2.0 to completely replace session? I.e., even people are using the website designed by me (NOT third party website) to access my own server? So that I have a unified authorization framework for user accesses both from my own website and any thrid party website.
Is there any pros&cons of using session & oauth 2.0?
Lastly, how about mobile app? I know for third party mobile app, they normally use oauth to access the server (many websites provides oauth api). How about if I am going to write my own app for my own server (NOT third party)? Does Oauth 2.0 apply here too?
To summarize, my question is actually is, is Oauth 2.0 universal that can be used in all kinds of user authorization control situations from all kinds of devices?
Thank you very much.
Though both are short-living entities, session IDs and OAuth tokens are fundamentally different and used for distinct scenarios. A session is used to identify a user of a web application, thus related to the end user. An OAuth token is used to grant access to a third-party service to access a limited set of protected user resources (e.g. read user contact information or send a mail from the user account). Though the token refers to the granter (i.e. end user authorized the grant), the token related more to the third-party application.
To give you an analogous example: imagine that you have a safe at your bank (i.e. your protected resource). The session is your id for the bank: give it to someone else and he will be you, he can get everything from your safe. On the other hand, a token is a limited authorization to someone else to your safe: e.g. your approval that he can get 10$ from your safe while a security guard is watching.
As a summary, sessions and tokens are not interchangable.