nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Oracle Communities

Oracle Analytics and AI

Child Item

iBot/ Agent: Separate Administration Role

Subhakara Netala-Oracle

Here I am suggesting to have a separate Administration Role exclusively for Agents/ iBots. Till now users are not able to edit other users Agents due to limitation in Product. If any of the user left the team or organization then those Agents are to be stopped or Assigned to some others by BI Administrator. If we have separate Admin Role for Agents like we have for Service Administrator, then Users(may be one or two Super Users) can be part of this new role and they can manage their own Agents without BI Administrator intervene.

If the owner of the Agent is on leave and that particular Agent to be stopped for sometime that is also not possible by any other users, even then users have to approach Admin to do needful. To avoid all these kinds of issues or dependencies there should be a separate role for Agent(which is going to be assigned to users), so BI Agent Administrator will manage all the Agents related activities.

Find more posts tagged with

Agents

Report Delivery

Scheduling or Agents

Needs Votes

Status: Needs Votes

Comments

Marcelo Finkielsztein

i respectfully disagree.

i believe Oracle should fix the current permission error. instead of investing resources on this suggestion. By the way, you could implement your suggestion right away today as an alternative. if i understood correctly, your idea requires sharing passwords; this is considered bad practice in lots of organizations nowadays; (including my employer )

AFAIK this problem is not a limitation but a bug. The existing security design would be enough, if the errors were solved. agent owners should be able to share, assign permissions, and agents saved in shared folders should react to their current security configuration or inherit from the folder in an appropriate way.

A previous Idea asking Oracle to fix the problem was submitted long ago.

Just my humble, honest, respectful opinion. Thanks

marcelo

p.s.

this is what i do today to deal with the error: an admin updates "run as" and ownership of the agent, moving from the previous owner to a new one. the admin does ONLY this. the admin does not touch the agent configuration; only transfers the agent to a new owner. once moved, the admin notifies the new "owner" and the owner remains on charge from now on.

Subhakara Netala-Oracle

@Marcelo Finkielsztein, thanks for your comments. Sharing password is strictly denied in any organization. My Idea is not sharing password. We can assign a multiple users to a single Application Role, we can have 2 or 3 BI Administrators. so can for Agent Administrator.

As I remember from Oracle documentation, Agents are only for user specific, that is the reason other user is not able to edit. Not sure weather this is going to be changed or not. That is the reason I have suggested a new Admin Role exclusively for Agents. So that we can add Super Users(who can manage their Agents) from users community this Role.

My Request is also to change the ownership to new user without BI Admin intervention. This Role exclusively for Agents only. Other Admin related tasks should not be visible to this Role.

Marcelo Finkielsztein

I started with OAC a few years ago. During the first month, I detected this issue. back then, this was not documented as a product known characteristic. it was a bug. on our on premise instance this was working properly and did not need to be changed at all. the security and permission and ownership of an agent had the same properties as seen on a dashboard or an analysis or any other OBIEE object.

The only point different with an agent is the "run as" impersonating property. back then, in on premise OBIEE, oracle was not considering this as a security problem, as far as i remember. we used to have teams of developers working as peers and editing agents disregarding who the author was, as long as the user had Edit permission to the agent.

My suspicion is that someone indicated this Run-As feature as a vulnerability; and oracle reacted to that, and came up with a so-called "solution" without realizing they were causing administrative problems. ie: when an agent author goes on vacation, other authors cannot cover for her/him.

About Security Policies:

Agree that sharing pwds should be forbidden everywhere!

in my organization, we are also strongly committed to restricting each user to only one Identity. our security officers would not accept that a business user can login as a native user. every user uses their unique Active Directory credentials. No chance of assuming a different Identity. And identities defined outside AD, using username+password are deeply discouraged.

IMHO, a rational solution to this is: improve the security audit trail, in a way that security auditors can monitor and track down WHO seems to be breaching Security or has taken an action that is deemed as risky.

HTH

Paula Jaime

We also need that role (a separate Administration Role exclusive for Agents/ iBots) for users responsible for agent management (who does not have BI admin role). They need to monitor the execution of all agents as a whole (have access to the Admin View option in Delivery Monitoring) and, if necessary, modify another user's agent.

Thank you.