I am currently handling my database user groups with ACLs. This works okay as per below and as per my logic and models. I'm mainly doing this because ACLs seem easier to implement. Parse has a somewhat confusing example using both CLPs and ACLs.
I would like to know if there is advantage to using CLPs over ACLs as I'm doing below or is my solution satisfactory, I.E. would what I'm doing below encounter any issues of any kind?
I'm using Parse & Back4App.
My demo project:
/*
Info: each user will have list of all authorized users ACL (user.objectID) and these
will all be written to any object crud actions.
*/
Future<void> saveUser001GroupData() async {
final acls = ParseACL();
var box = await Hive.openBox<String>(user001GroupIDsBox);
user001GroupIDs = box.values.toList();
for (final id in user001GroupIDs) {
acls.setReadAccess(userId: id, allowed: true);
acls.setWriteAccess(userId: id, allowed: true);
}
for (final color in user001GroupData) {
color.setACL(acls);
await color.save();
}
}
Related
I have a question regarding a small issue that I'm having. I've created a widget that will live on the Service Portal to allow an admin to Accept or Reject requests.
The data for the widget is pulling from the Approvals (approval_approver) table. Under my GlideRecord, I have a query that checks for the state as requested. (Ex. addQuery('state', 'requested'))
To narrow down the search, I tried entering addQuery('sys_id', current.sys_id). When I use this query, my script breaks and I get an error on the Service Portal end.
Here's a sample of the GlideRecord script I've written to Accept.
[//Accept Request
if(input && input.action=="acceptApproval") {
var inRec1 = new GlideRecord('sysapproval_approver');
inRec1.addQuery('state', 'requested');
//inRec1.get('sys_id', current.sys_id);
inRec1.query();
if(inRec1.next()) {
inRec1.setValue('state', 'Approved');
inRec1.setValue('approver', gs.getUserID());
gs.addInfoMessage("Accept Approval Processed");
inRec1.update();
}
}][1]
I've research the web, tried using $sp.getParameter() as a work-around and no change.
I would really appreciate any help or insight on what I can do different to get script to work and filter the right records.
If I understand your question correctly, you are asking how to get the sysId of the sysapproval_approver record from the client-side in a widget.
Unless you have defined current elsewhere in your server script, current is undefined. Secondly, $sp.getParameter() is used to retrieve URL parameters. So unless you've included the sysId as a URL parameter, that will not get you what you are looking for.
One pattern that I've used is to pass an object to the client after the initial query that gets the list of requests.
When you're ready to send input to the server from the client, you can add relevant information to the input object. See the simplified example below. For the sake of brevity, the code below does not include error handling.
// Client-side function
approveRequest = function(sysId) {
$scope.server.get({
action: "requestApproval",
sysId: sysId
})
.then(function(response) {
console.log("Request approved");
});
};
// Server-side
var requestGr = new GlideRecord();
requestGr.addQuery("SOME_QUERY");
requestGr.query(); // Retrieve initial list of requests to display in the template
data.requests = []; // Add array of requests to data object to be passed to the client via the controller
while(requestsGr.next()) {
data.requests.push({
"number": requestsGr.getValue("number");
"state" : requestsGr.getValue("state");
"sysId" : requestsGr.getValue("sys_id");
});
}
if(input && input.action=="acceptApproval") {
var sysapprovalGr = new GlideRecord('sysapproval_approver');
if(sysapprovalGr.get(input.sysId)) {
sysapprovalGr.setValue('state', 'Approved');
sysapprovalGr.setValue('approver', gs.getUserID());
sysapprovalGr.update();
gs.addInfoMessage("Accept Approval Processed");
}
...
Working on a Teams chatbot (V4/Node) and need to address GDPR.
In short, users of the chatbot need to be able to export or delete their personal data stored by the chatbot. Personal data is any information which is related to an identified or identifiable natural person. So also a user-ID in a state object.
I read a blog about GDPR and bots but this one does not address the Teams channel. And it is about V3
The personal data given by the user in dialogs (written by me) is
the easy part. I will write some dialogs to show and delete them
(like Bill does in his answer).
The content in the actual conversations is part of the Teams platform and will\should be adressed in Teams itself.
The bit I don't know how to address is the data for the bot to actually run (Bot state etc). What if a user needs to delete the fact that he or she participated in a certain conversation. That is probably stored in some state objects (in my case in Blob storage). But which ones?
I would appreciate some ideas\guidance in how to address this.
Disclaimer: I'm not a GDPR expert but I believe the following to be sufficient.
From a bot standpoint the data stored is the same in Teams channel. You have the conversation state and user state data which is typically (and in most of the examples) set up using Blob storage. I use the conversationState and userState nomenclature for these items.
In my use case, I am storing account number in userState and user name/email in conversationState. Note that there are other things that the bot stores (particularly in conversationState I believe) around the state of the dialog and other bot specific things that are rather meaningless generally but I don't know if they would be considered part of GDPR. Regardless we will be wiping these entire objects out.
To do that, I created a dialog to manage the user profile which displays the key information stored (I'm specifically accessing account number, user name, and email) and then prompts the user for if they want to delete the information. It looks like this in nodejs.
const { ConfirmPrompt, ComponentDialog, WaterfallDialog } = require('botbuilder-dialogs');
const { ActivityTypes } = require('botbuilder');
const WATERFALL_DIALOG = 'waterfallDialog';
const CONFIRM_PROMPT = 'confirmPrompt';
class manageProfileDialog extends ComponentDialog {
constructor(dialogId, userDialogStateAccessor, userState, appInsightsClient, dialogState, conversationState) {
super(dialogId);
this.dialogs.add(new ConfirmPrompt(CONFIRM_PROMPT));
this.dialogs.add(new WaterfallDialog(WATERFALL_DIALOG, [
this.showInfoAndPrompt.bind(this),
this.confirmDelete.bind(this)
]));
this.initialDialogId = WATERFALL_DIALOG;
// State accessors
this.userDialogStateAccessor = userDialogStateAccessor;
this.userState = userState;
this.dialogState = dialogState;
this.conversationState = conversationState;
this.appInsightsClient = appInsightsClient;
} // End constructor
async showInfoAndPrompt(step) {
this.appInsightsClient.trackEvent({name:'manageProfileDialog', properties:{instanceId:step._info.values.instanceId, channel: step.context.activity.channelId}});
this.appInsightsClient.trackMetric({name: 'showInfoAndPrompt', value: 1});
const userProfile = await this.userDialogStateAccessor.get(step.context, {});
const conversationData = await this.dialogState.get(step.context, {});
if (!userProfile.accountNumber & !conversationData.userEmail & !conversationData.userFullName & !conversationData.orderType) {
this.appInsightsClient.trackEvent({name:'manageProfileDialogEnd', properties:{instanceId:step._info.values.instanceId, channel: step.context.activity.channelId}});
this.appInsightsClient.trackMetric({name: 'confirmDelete', value: 1});
await step.context.sendActivity(`I don't have any of your information stored.`);
return await step.endDialog();
} else {
var storedData = '';
if (userProfile.accountNumber) {
storedData += ` \n**Account Number:** ${userProfile.accountNumber}`;
}
if (conversationData.userFullName) {
storedData += ` \n**Name:** ${conversationData.userFullName}`;
}
if (conversationData.userEmail) {
storedData += ` \n**Email:** ${conversationData.userEmail}`;
}
if (conversationData.orderType) {
storedData += ` \n**Default order type:** ${conversationData.orderType}`;
}
await step.context.sendActivity(`Here is the informaiton I have stored: \n ${storedData} \n\n I will forget everything except your account number after the end of this conversation.`);
await step.context.sendActivity({ type: ActivityTypes.Typing });
await new Promise(resolve => setTimeout(resolve, process.env.DIALOG_DELAY));
return await step.prompt(CONFIRM_PROMPT, `I can clear your information if you don't want me to store it or if you want to reneter it. Would you like me to clear your information now?`,['Yes','No']);
}
}
async confirmDelete(step) {
this.appInsightsClient.trackEvent({name:'manageProfileDialogEnd', properties:{instanceId:step._info.values.instanceId, channel: step.context.activity.channelId}});
if (step.result) {
const userProfile = await this.userDialogStateAccessor.delete(step.context, {});
const conversationData = await this.dialogState.delete(step.context, {});
await step.context.sendActivity(`OK, I have cleared your information.`);
return await step.endDialog();
} else {
await step.context.sendActivity(`OK, I won't clear your information. You can ask again at any time.`);
this.appInsightsClient.trackMetric({name: 'confirmDelete', value: 1});
return await step.endDialog();
}
}
}
module.exports.ManageProfileDialog = manageProfileDialog;
One thing I am uncertain of regarding GDPR is if you are storing transcripts or activity data elsewhere in the course of running the bot. For example, I am storing conversation transcripts in CosmosDB, which could include things like names and email addresses if they were provided during the course of the conversation. I don't have a good way to clear this information even if I wanted to. Also, I am storing LUIS traces and other information in Application Insights, which in many cases includes the activity which may have things like user name or ID attached. I'm not even sure it would be possible to delete those traces from Application Insights. I do not know if these fall under the realm of GDPR since they are operational, but if that is a potential concern just be careful about what you are storing in your logging and/or transcript applications.
I am trying to use IdentityServer4 in a new project. I have seen in the PluralSight video 'Understanding ASP.NET Core Security' that IdentityServer4 can be used with claims based security to secure a web API. I have setup my IdentityServer4 as a separate project/solution.
I have also seen that you can add an IProfileService to add custom claims to the token which is returned by IdentityServer4.
One plan is to add new claims to users to grant them access to different parts of the api. However I can't figure out how to manage the claims of the users on the IdentityServer from the api project. I assume I should be making calls to IdentotyServer4 to add and remove a users claims?
Additionally is this a good approach in general, as I'm not sure allowing clients to add claims to the IdentityServer for their own internal security purposes makes sense - and could cause conflicts (eg multiple clients using the 'role' claim with value 'admin'). Perhaps I should be handling the security locally inside the api project and then just using the 'sub' claim to look them up?
Does anyone have a good approach for this?
Thanks
Old question but still relevant. As leastprivilege said in the comments
claims are about identity - not permissions
This rings true, but identity can also entail what type of user it is (Admin, User, Manager, etc) which can be used to determine permissions in your API. Perhaps setting up user roles with specific permissions? Essentially you could also split up Roles between clients as well for more control if CLIENT1-Admin should not have same permissions as CLIENT2-Admin.
So pass your Roles as a claim in your IProfileService.
public class ProfileService : IProfileService
{
private readonly Services.IUserService _userService;
public ProfileService(Services.IUserService userService)
{
_userService = userService;
}
public async Task GetProfileDataAsync(ProfileDataRequestContext context)
{
try
{
switch (context.Client.ClientId)
{
//setup profile data for each different client
case "CLIENT1":
{
//sub is your userId.
var userId = context.Subject.Claims.FirstOrDefault(x => x.Type == "sub");
if (!string.IsNullOrEmpty(userId?.Value) && long.Parse(userId.Value) > 0)
{
//get the actual user object from the database
var user = await _userService.GetUserAsync(long.Parse(userId.Value));
// issue the claims for the user
if (user != null)
{
var claims = GetCLIENT1Claims(user);
//add the claims
context.IssuedClaims = claims.Where(x => context.RequestedClaimTypes.Contains(x.Type)).ToList();
}
}
}
break;
case "CLIENT2":
{
//...
}
}
}
catch (Exception ex)
{
//log your exceptions
}
}
// Gets all significant user claims that should be included
private static Claim[] GetCLIENT1Claims(User user)
{
var claims = new List<Claim>
{
new Claim("user_id", user.UserId.ToString() ?? ""),
new Claim(JwtClaimTypes.Name, user.Name),
new Claim(JwtClaimTypes.Email, user.Email ?? ""),
new Claim("some_other_claim", user.Some_Other_Info ?? "")
};
//----- THIS IS WHERE ROLES ARE ADDED ------
//user roles which are just string[] = { "CLIENT1-Admin", "CLIENT1-User", .. }
foreach (string role in user.Roles)
claims.Add(new Claim(JwtClaimTypes.Role, role));
return claims.ToArray();
}
}
Then add [Authorize] attribute to you controllers for your specific permissions. This only allow specific roles to access them, hence setting up your own permissions.
[Authorize(Roles = "CLIENT1-Admin, CLIENT2-Admin, ...")]
public class ValuesController : Controller
{
//...
}
These claims above can also be passed on authentication for example if you are using a ResourceOwner setup with custom ResourceOwnerPasswordValidator. You can just pass the claims the same way in the Validation method like so.
context.Result = new GrantValidationResult(
subject: user.UserId.ToString(),
authenticationMethod: "custom",
claims: GetClaims(user));
So like leastprivilege said, you dont want to use IdentityServer for setting up permissions and passing that as claims (like who can edit what record), as they are way too specific and clutter the token, however setting up Roles that -
grant them access to different parts of the api.
This is perfectly fine with User roles.
Hope this helps.
In my bot I would like to accept attachments from users.
I know how to receive them in :
public async Task<Message> Post([FromBody]Message message)
{
if (message.Type == "Message")
{
if (message.Attachments.Count > 0)
{
foreach (var afile in message.Attachments)
{
lstFiles.Add(afile.ContentUrl);
}
}
what I am doing here is storing them as they arrive in lstFiles that is list of strings private to class MessagesController : ApiController, this way I know I can have those files and their URLs
When users finishes answering the questions ( I am using FormFlow) in the Do event I store his input in Azure storage table
internal static IDialog<VGMData> MakeRootDialog()
{
return Chain.From(() => FormDialog.FromForm(VEMData.BuildForm))
.Do(async (context, order) =>
{
var completed = await order;
StoreAndSendEmailConfirmations(completed);
await context.PostAsync("And I am done... ..");
}
I can not understand how can I have access to attached files in the .Do function so that I can initiate download and subsequent storage in azure blob for files submitted by user and within his conversation. Only thing I seem to have is 'context' and 'order' that is user data replies but without attachment files.
I can get there lstFiles, but I am afraid it may contain files from different simultaneous users and conversations.
thanks in advance,
Roman
You might want to consider storing the list of attachments in the PerUserPerConversation data bag. In that way you can ensure that you will be retrieving the data related to the user participating in that conversation.
Here is the documentation around how the bot track state.
Can we tune the performance of default asp.net web api 2 identity provider.
If I am not using the roles or claims, can I exclude them from the query generated by the identity provider. This may help improve the performance a lot.
I am referring to the class ApplicationOAuthProvider.cs created by the default web api project.
The steps that it follows is:
var user1 = await userManager.FindByNameAsync(context.UserName);
if (user1 == null)
{
context.SetError("invalid_grant", "The user is not registered.");
return;
}
//Query gets executed once here
ApplicationUser user = await userManager.FindAsync(context.UserName, context.Password);
if (user == null)
{
context.SetError("invalid_grant", "The user name or password is incorrect.");
return;
}
// Query gets executed once again here
ClaimsIdentity oAuthIdentity = await user.GenerateUserIdentityAsync(userManager,
OAuthDefaults.AuthenticationType);
//This one generates one more query
ClaimsIdentity cookiesIdentity = await user.GenerateUserIdentityAsync(userManager,
CookieAuthenticationDefaults.AuthenticationType);
//Fires the same query as above
AuthenticationProperties properties = CreateProperties(user.UserName);
AuthenticationTicket ticket = new AuthenticationTicket(oAuthIdentity, properties);
context.Validated(ticket);
context.Request.Context.Authentication.SignIn(cookiesIdentity);
THE WHOLE PROCESS TAKES 4 SECONDS. AM I DOING ANYTHING WRONG HERE?
Can we eliminate some process / merge few of them and optimize the
same.
Thanks
We sort of have the same setup.
Does it happen on every single request?
We've had quite alot of problems with entity framework cold queries and view generation, however, the "second" query always goes really fast.
If that is the case you can try using ADO.net with Identity instead and pregenerate views for entity framework. However, it's still a messy solution and something I really think MS should adress.
The article is still very relevant regarding identity, and there by entity framework, "warm-up".