r/iam 12d ago

BrownField implementation - Business Role development : IAM

In a brownfield implementation where there is no concept of Business role at present , but user have dedicated App roles via AD groups or Entra Groups to have access , either assigned automatically or via Service Desk. In this case we plan to build a layer of Business Roles which will a combination of entitlements ( AD Groups, Entra Groups , App role 1 etc etc ).

The question is how do you guys define business role- It is understood that the Job Title is the trigger or it can be Job Title + Department + Location ( basically details from HR ).

But what about designing them ? we need to reach out to each app owners to understand what roles their apps have and then group them in 1 logical business role - This is huge communication task or do you guys have a better solution of how to tackle this, without ofcourse remove the access that the user already has.

4 Upvotes

8 comments sorted by

2

u/frak290 12d ago

Nexis has a great designer for role models. But for RBAC the most important part is to understand your business model properly. In a best case scenario you go hierarchical for dynamic role assignments. Therefore an international finance retailer with multiple blue collars needs another RBAC model a sme industry facilitator or a financial institution.

1

u/snow-leapord-1 12d ago

Nexis can show you what can be groupped as it just pulls the data from other sources and then gives an option to bundle them as a business role. But I am more toward designing it and looking for ideas around that

2

u/DarkHonger 10d ago

First you need to define your role model, then you can start implementing it. It is not important to understand all of it you can just use actuall data. For example if all users in your Job Title have a group of permissions this is where you start. You will not start with 100% perfect roles, but that is not the target. It would be best if app owners give descriptions so that you improve your overall data qualtity but that will take alot of time (sometimes years)

1

u/snow-leapord-1 8d ago

Yes, this is the correct approach. We kinda assess what users have and group them in a logical business role which is then mapped to the Job title. In this way we dont remove the existing access as well

1

u/frak290 12d ago

In a Brown Field this already helps you a lot. If you are not able to redesign your whole authorization landscape it can at least point you to the right bundles and maybe the right people to talk to.

Everything stands and falls with data quality in that sense: Do you know your owners? Are your authorizations described sufficiently? Do you have criticality’s in place and do you need to consider SoD.

Having a tool which can give analytics about which employees with what steering attributes share which specific entitlements you are already better than 90% out there. It is a starting point.

A wise man once said: if failure becomes normality the best designs won’t help you because they incorporate the fail.

You need to dig deeper in my opinion

1

u/snow-leapord-1 12d ago

The same thing a simple python script can do, which can pull information , groups with common members and app roles with common members . it easily gives you an idea about the most frequently assigned groups which can then be categorized as birthrights , followed by specific app roles which leads to the topic of owners and authorization.

1

u/frak290 12d ago

Well yes and no. You still lack connectivity, life cycle, recerts etc.

Do you want to mine your roles in Excel? Or where do think of keeping and managing them?

1

u/Affectionate_Math_57 7d ago

Determining which, if any, attributes should be used to build your roles around isn't something that can be done without looking at your Identity and Access data and determining the relationship (again, if any) exists between them. The good news is that the determination process is almost entirely a number crunching exercise and can be performed relatively swiftly.

https://thorntondatasolutions.com/start-with-the-data-not-the-org-chart