We got a race condition coming from OneLogin APIs where the User added to Role event is coming in before the User created event if the customer is leveraging mappings.This causes the race condition in which we do not send events to automation and kick off workflows based on WHEN user is added to a ROLE and IF Role is 'X'
Basically we receive the event for user added to role but we fail to trigger the workflow for the customer. Need to understand why OneLogin is creating the user added to role event before the user create event in their audit log. https://screenshots.bettercloud.com/jkuWEke4
Example:
In OneLogin I have the following Mapping: https://screenshots.bettercloud.com/yAuQ0R9W
When I create a user: https://screenshots.bettercloud.com/qGuxR8YX
OneLogin Audit Log (notice the role comes before the creation): https://screenshots.bettercloud.com/qGuxR8BB
Steps to recreate in BetterCloud Platform:
create a workflow for OneLogin WHEN user is added to role and IF role is X
In OneLogin create a mapping that adds a user to role X when
department, or any other condition is met. (the condition must be
set at time of user creation)
Create user that will trigger the mapping, in my example I used
department = support
Check the OneLogin Audit Log (role comes before create event)
Check BetterCloud GCP logs (Role comes before create event)
workflow does not trigger
Expected result: workflow triggers similar to Okta
Related
I want to update a Subscription of an Azure Event Grid Partner Topic to change the ExpirationDateTime.
To do so I'm using a PowerShell AzureFunction authenticated with an App Registration on GraphAPI. I'm using the Update-MgSubscription function to update the field above.
When I execute the function I get the following error message: "The app id 'appid' is not enabled for event grid subscription." where 'appid' is the id of my App Registration.
I was able to update the field with Graph Explorerbut I couldn't manage to find a specifc permission to do it with the App Registration. I've tried to allow the App in the IAM of the Azure Event Grid Partner Topic with no success.
Any idea?
"The app id 'appid' is not enabled for event grid subscription."
This error occurs when the App Registration you're using lacks the required permissions to update the Event Grid subscription. You will need to grant the necessary permissions to your App Registration to resolve this issue.
You mentioned that you tried to allow the App in the Azure Event Grid Partner Topic's IAM before, but it didn't work. This is due to the reason that updating the subscription requires permissions at the Azure Event Grid system level, rather than just the topic level.
To grant the necessary permissions, Check below:
Select your Azure Event Grid System topic and Goto Access Control (IAM) -> Add a role assignment and search for Event Grid contributor role and then assign to the registered application. Now it will manage all the operations for the Event subscriptions.
I created a system topic in my subscription and added a relevant permission as shown below:
System topic:
Role Assignments:
Is it possible within Azure devops to send a bespoke notification to a user when a work item is completed.
Example Scenario
Work item are logged in azure devops under project by user 'Y' on behalf of a user 'X'
When this work item is completed is it possible to automate an email to user 'X'. Saying something like your request has been completed.
User 'Y' = Member of development team
User 'X' = End user of system, who has requested feature
Is this possible to achieve or is there a better way to go about this process ?
I think, this is possible but azure devops should detect your X by some properties. I see two ways:
User X may to Follow a work item.
User Y may create some specific tag and you can create a custom notification for that tag:
Or create a custom application that will scan your work items and send notifications.
I am trying to achieve fairly simple usecase of role based client application (VueJS multi-page applications) control using the keycloak.
As shown in image, I have three different roles and three different clients in single realm.
The arrow in the image represents which role can access which client.
So my main objectives are,
User with role Viewer should only be able to log-in to the Viewer Application. If the same user tries to access the Operator Application or Admin application then keycloak should simply deny this user from doing so.
The same rules should follow for users with Admin and Operator role. Users of Admin role should be able to log-in to any of these application by keycloak.
To achieve this usecase I tried following ways,
First by appropriate role mapping to users and role creation in the clients. In this case, I create realm level roles and then client level roles, then assigned appropriate roles to the users created in the user section.
Enabling the Authorization. In the policies, I removed default policy that grant all users access to the client. And create a User policy and Client policy to restrict the access to client application
Also tried with Group based authorization policy. In this case, I created a group with client role and then assigned user to these groups. And enabled them from the Authorization group policy.
But, unfortunately none of this works. Meaning my user with Viewer role can log-in to my admin application. Which is just strange.
You can do this without extensions.
Copy the desired flow (e.g. the browser flow)
Create a new sub flow (e.g. for the browser forms) and call it Access By Role and select generic as type.
For the new sub flow ensure that CONDITIONAL is selected in the flow overview.
For the new sub flow add execution Condition - User Role, make it REQUIRED and configure it:
alias: admin-role-missing
role: admin (or whatever your role is)
negate: true
Add another execution: Deny Access and make it REQUIRED as well.
The final result should look similar to this:
This will deny access if the condition "admin-role-missing" is true.
You an also learn more from the docs: explicitly-deny-allow-access-in-conditional-flows
Also, don't forget to go to your client and select the flow in the authentication overrides.
The solution proposed by #Stuck is a great start, but it has a significant flaw: When the user has already authenticated, e.g. via the standard flow of another client that did not require the role, the password form flow will never be triggered. Consequently, the user will be logged in via the cookie flow without ever checking for the role.
In other words: If there are other clients (such as the account console) that do not require the role, anyone can bypass the role check.
To fix this there needs to be an additional flow layer that includes all authentication executions, that is followed by the authorization step (no matter what authentication flow was used). The final result will look like this:
I managed almost the same problem using KeyCloak extension SPI. After the deployment you will have additional configurable "execution" in authentication flows available, named "Validate User Role".
The auth flow then look's like :
This execution must be placed after the "Username Password Form" (or other form which authenticates user) or the authentication will fail.
The source code is here :
https://github.com/ValentinChirikov/kc_user_role_validate_extension
Finally handled this at the application level as it wasn't working from keycloak end.
After the login, check for the keycloak object, inspecting on the same we can find some of the useful properties set during the configuration mentioned in the question above. The overall code looks like below,
let appName = 'your_app';
keycloak.init({ onLoad: 'login-required' }).success(function () {
// Confirm the role & authentication of the user
if (keycloak.authenticated && keycloak.tokenParsed.resource_access &&
keycloak.tokenParsed.resource_access.hasOwnProperty(appName)) {
// Continue with the app execution...
} else {
// Logout user
keycloak.logout();
}
}).error(function () {
keycloak.logout();
});
This way I managed to route unauthorized user out of the application.
The solution isn't what's required in the question asked, but it works. Although I think this should be handled at the keycloak level itself.
For anyone looking to do this in Keycloak version 20, see the screenshot. This is based on answer by #heilerich but for version 20.
NOTE: Create a new flow instead of duplicating an existing flow as it will not work.
I am trying to create new alert to send notification at new permission created but i didn't get what i want .
This what i am talking about:
As I understand, I think you are asking for an alert to be generated when an role assignment is made in your subscription. If yes,
You may use Azure Monitor for your use case.
In Azure Monitor blade, you need to create an alert as follows
a. Specify the target resource (in your case, your subscription),
b. Define an alert criteria (when you configure signal, choose administrative activity log > create role assignments / delete role assignments)
c. Create an action group. You can specify an email address to which the alerts will be sent
Once setup, every time a new role is assigned, an email alert will be sent to the email id specified in the Action Group
You may explore Event Grids also for your scenario
I need to be able to make one user temporarily mirror another on demand. The mirroring user should get the same business unit, teams, and roles as the target user. Right now it is done manually, but it's a pain. I wrote a custom workflow activity to do it and it works if I run it as a system administrator and pick a mirroring user and target user.
But the end goal is to be able to allow certain users to run the dialog themselves. If I try to run it with myself as the mirroring user I get an error saying I don't have the privilege to assign roles, which makes sense since the workflow takes away my roles and then tries to assign me the target user's roles.
I'd like for the workflow activity to run as a privileged user but haven't had any luck so far. I've tried creating the IOrganizationService like this:
var context = executionContext.GetExtension<IWorkflowContext>();
var serviceFactory = executionContext.GetExtension<IOrganizationServiceFactory>();
var service = serviceFactory.CreateOrganizationService(null);
According to the documentation calling CreateOrganizationService with null as the parameter should force the user of the System user but it appears to still be running as the calling user.
I also tried calling CreateOrganizationService and passing the Guid of a different user with the System Administrator role, but got the same results.
Workflows has special conditions and is designed to ignore the guid you pass to the CreateOrganizationService.
I take the next paragraph from this article:
For the automatic workflow case, the owner of the workflow is also the
person who activates it and who selects the trigger mechanism and the
workflow steps so it is OK if the workflow executes under that user’s
context. For the on-demand case, a user is specifically requesting
some actions to be performed on his behalf by a workflow so the user
is fully aware of the workflow definition and that it will execute;
therefore it is safe to execute the workflow under that user’s context
instead of the workflow owner (who might not be aware that a user
requests an on-demand execution).
The custom workflow activity could be converted to a plug-in registered to run in the context of CRM Service or an Administrator
The workflow could be automatically, rather than manually triggered
If the end users are explicitly starting the workflow, it will be running in their user context
Dialogs are always run in the initiating users context
A workflow triggered by an event rather than being explicitly started by the user will run in the context of the user who started, and owns, the workflow - in this case an Administrator
A dialog or custom ribbon button could change something (a custom field) on the record that your custom workflow activity is registered to execute on-change