<div dir="ltr">HI Marc,<div><br></div><div>thanks for the explanation.</div><div><br></div><div>can you please share some kind of implementation guide for this?</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 16, 2016 at 3:45 AM, Marc Boorshtein <span dir="ltr"><<a href="mailto:marc.boorshtein@tremolosecurity.com" target="_blank">marc.boorshtein@tremolosecurity.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I would like to know more about RBAC. like what is RBAC and what can be<br>
> achieved with RBAC.<br>
><br>
> anyone please share some good topics about this as i am getting so many and<br>
> the information's mentioned on those are different.<br>
<br>
</span>I can imagine.  RBAC (Role Based Access Control) was created on the<br>
idea that what systems, applications and entitlements you need should<br>
be based on your job function.  Its a way of mapping business policies<br>
to to technical authorizations.  An example would be that someone in<br>
accounts payable shouldn't have access to the same systems as someone<br>
from accounts receivable.  So in RBAC terms you would have a "Role"<br>
called "Accounts Payable" that might map to groups in a directory for<br>
"access to check system" and "access to vendor system" but another<br>
"Role" called Accounts Receivable that has access to other groups.<br>
Then you have something to audit against "Why does someone with Role X<br>
have groups that aren't tied to that role?".<br>
<br>
In practice, this rarely works.  Few enterprises do that good of a job<br>
defining the roles and responsibilities for their employees at an HR<br>
level that trying to enforce those roles in technology is hopeless.<br>
Also, RBAC models are very rigid and hard to change so if you need to<br>
grant someone access to a system thats "one off" to get something done<br>
it breaks the entire model (unless your technology can handle it).<br>
What often happens is you get into a situation where every user could<br>
have their own role, completely breaking the RBAC model.<br>
<br>
In my decade plus of identity management implementations across pretty<br>
much every vendor and several industries I can't think of any RBAC<br>
based models that were successful, but several that were complete<br>
failures.  I was told going into a meeting at one large customer<br>
"Don't even mention RBAC or the meeting will be ended and we'll be<br>
out."<br>
<br>
Hope that helps<br>
<br>
Thanks<br>
<span class="HOEnZb"><font color="#888888">Marc<br>
</font></span></blockquote></div><br></div>