Posts Tagged ‘RBAC’

« Older Entries

The ABAC tie in to RBAC, RAdAC and SAML

Monday, September 19th, 2011

I was in a conversation recently in regards to Extensible Access Control Mark-up Language (XACML) and  Attribute Based Access Control’s (ABAC) role in Role Based Access Control (RBAC), Risk Adaptable Based Access Control (RAdAC) and Security Access Mark-up Language (SAML).  The question surrounded whether ABAC can or should replace the other Access Control models and/or the open standard languages.

The short answer is no, and well, kind of yes.

Let me expound upon my vagary if you will.

Role Based Access Control (RBAC)

To start with Role Based Access Control we should start with what works.   The RBAC tools on the market have an advantage of tying the Identity to a Role that can be used for high level access rights that don’t need to change all that often.  Aveksa, Sailpoint, Oracle Identity Analytics, etc. pride themselves on the ability to role mine your application stack and set the role to the associated entitlements.  This allows the organization to fulfill most security audits and allows for easy re-certification of said roles quarterly, bi-annually, annually or whatever the requirement states.  The failing, if you were to call it such, is that to change the entitlements typically becomes very intricate as the roles the organization has explodes.  This forces the governance model to keep roles shallow at best.

Where ABAC shines is by allowing a deeper, more fine-grained authorization model by using policy combined with attribute values in order to allow a level of authorization commensurate with the values presented.  To do this, ABAC essentially strips out the Identity and relies solely on those attribute values to make a decision.  This can extend an RBAC separation of duty (SOD) policy greatly and alleviate a lot of risk while making SOD decisions in real time.

So while “yes”, you can replace your RBAC vendor’s toolset with an ABAC solution the real question is why would you?  The tools work very well together and allow for a greater sum of their parts as opposed to their own private silos.  If I had my druthers within my customer sites I would have an Identity Provisioning system (to automate Identity creation and management) that ties into my RBAC vendor tool (to grant high-level entitlements and set automated recertification policy) that leverages my ABAC tool to authorize application access at a fine grained level (with perhaps an SSO tool to manage Authentication, which XACML/ABAC does not).

Risk Adaptive Based Access Control (RAdAC)

Ah RAdAC, the grand unknown!  RAdAC essentially is the process of taking information we know about the user, whether that is attributes, meta-data or some other method of taking a plethora (hopefully) of information, running said data into a risk engine algorithm and spitting out data to make a much more informed decision.  This is particularly important on highly classified systems.  In this case ABAC is a natural fit in conjunction with a RAdAC tool in which the RAdAC tool becomes the defacto decision engine with ABAC the data provider (potentially as this can be some data aggregator like a virtual directory) and the authorization enforcer.  ABAC vendors can enforce based on classifications (such as meta-tagging your data as “Secret”,  “Top Secret” and “Confidential”) and can run policy based on location or various credentials much in the same way a RAdAC system so you can replace but again the why comes into play here.  RAdAC vendor tools typically have a better risk engine to help you define the risk algorithms instead of having to determine the set, write the policy and hope it doesn’t change.  Once again ABAC plays nicely with the additional Access Control method.

Secure Access Mark-up Language (SAML)

This time let’s dissect Extensible Access Control Mark-up Language (XACML ) vs. SAML.  This really isn’t a “Vs.” situation.  SAML tends to be used in the Authentication side of the house with limits on how deep it can go into Authorization.  Try locking down individual attribute lines in a web based widget framework with SAML.  It isn’t going to happen, but that is OK.   The point to XACML when used in conjunction with SAML is that it can extend the security framework by providing a more robust Authorization framework (i.e. fine-grained).  So don’t throw away your Web SSO vendor integration yet.  Can you? Well, once again the answer is “yes”, but why would you?  Keep your infrastructure and expand.  ABAC should not be used as a rip and replace technology, it is a flexible architecture that can “add to” instead of “take away”.

Long story short, ABAC is the nice kid on the playground that plays by himself until someone walks up and asks him to play.  Then he plays well with others.

Questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

Tags: , , , , , , , , , , , , ,
Posted in Access Management, Attribute Based Access Control (ABAC), Aveksa, Axiomatics, Best Practices, BiTKOO, Oracle Entitlements Server (OES), Oracle Identity Analytics, RAdAC, RBAC, Risk & Compliance, SAML, Single Sign On (SSO), XACML | No Comments »

IDMWORKS and BiTKOO Announce Strategic Partnership

Thursday, September 1st, 2011

IDMWORKS and BiTKOO announce strategic partnership

Miami, FL (September 1, 2011) IDMWORKS is pleased to announce the successful partnership with BiTKOO for their market leading fine-grained authorization product “Keystone”.

The IDMWORKS Identity and Access Management experts, have been delivering reference quality solutions since 2004 to public and private sector clients in the US and Canada. The IDMWORKS’ team of experts is certified and working with customers to demonstrate the exceptional value offered by the Keystone product suite within a heterogeneous development environment and complicated security landscape.

“Keystone’s value is realized within the first few minutes of a Demonstration or Proof of Concept. Developers are impressed by the flexibility and immediately begin to think of the opportunities to replace their archaic methods of implementing authorization within their enterprises. Our business community and Auditors welcome the adherence to standards (XACML 3.0) and consistency that Keystone introduces,” said Paul Bedi, Managing Partner and Co-Founder of IDMWORKS.

Doron Grinstein, CEO of BiTKOO said in a statement, “IDMWORKS has proven expertise in successfully implementing identity and access management projects. I’ve had the pleasure of working with the fine implementation engineers at IDMWORKS and can attest to their high caliber and experience in this field. I am very pleased to announce this partnership, which represents a win/win for our customers as well as for BiTKOO and IDMWORKS. I have no doubt that this relationship will help us expand even more rapidly in the fine-grained authorization space. It has seen tremendous growth in the past year and the projection for 2012 is that the market will more than double compared to 2011. I am very committed to our partnership and I look forward to serving many joint customers.”

About BiTKOO

BiTKOO is the global leader in XACML and fine-grained authorization software. More companies rely on Keystone, which is the first hybrid RBAC/ABAC XACML authorization software, than all other vendors in the field combined. Founded with the belief that identity and access management should be as simple and available as the telephone dial-tone, BiTKOO empowers customers to concentrate on their respective domains, while providing them with the knowledge and peace of mind that their identity and access control is provided by best-of-breed and standards-based solutions that are scalable and secure. Visit http://www.bitkoo.com to learn more.

About IDMWORKS

IDMWORKS is an expert-level Identity and Access Management consultancy having successfully driven 200+ IAM projects since 2004. IDMWORKS has been recognized for their leadership in security and their consultants are true domain experts as recognized by their peers, customers and partners. IDMWORKS is headquartered in sunny Miami, Florida. Visit http://www.idmworks.com and http://www.idmworks.com/blog to learn more.

###

Product and company names herein may be trademarks of their registered owners

Media Contacts


BiTKOO:
Share Ross. VP of Marketing
Share.ross@bitkoo.com
561-374-4582

IDMWORKS:
Paul Bedi
paul@idmworks.com
888-687-0436

Tags: , , , , , , ,
Posted in Attribute Based Access Control (ABAC), BiTKOO, IDMWorks | No Comments »

Best Practice Role Management Methodologies

Tuesday, July 26th, 2011

When developing Roles within an organization it is important to pre-select the proper Role Management Methodology for use on your project and for ongoing operations once your roles are ready to go live.  There are two approaches that can be used when developing access roles for a company or organization:

  • Top down – With this approach uses a pre-defined method of organizing user access based upon known or developed plan.  An example of this would be: defining user access based upon job function and what access that job requires as the method of organizing people into roles.
  • Bottom up -  With this approach you examine what access people currently have and assign roles based upon what rights those users have. An example of this would be: discovering what rights all (or a group) people have and selecting common access rights for the role being developed.

Both of these approaches have merits and drawbacks associated with their use such:

  • Top down

+  Most effective and comprehensive method of role development

+  Aligns access rights and compliance to business goals regarding compliance

-  Requires business and organizational understanding of access rights at the site

-  Requires significant time in role development before implementation

-  Often difficult to quantify all role assignments and proper access

-  Complexity often leads failure role development or “stuck in the weeds”

  • Bottom up

+  Quick role development

-  Highly difficult to quantify specific access rights for the roles developed

-  Requires access and mining of specific access data

-  Difficult to align business objectives and compliance with developed roles

It is has been my experience that using a hybrid approach using the following methodology will make a role discovery project successful:

  • Top + Bottom Role discovery – This method uses one or more business or organizational top down role methods and follows with a bottom up approach for discovery and verification.  An example of this would be: take employees job codes as the basis for role creation and locate the access rights associated with the job codes.  Use manual or campaign determination of proper access rights for the roles developed.
  • 80 / 20 Rule - The goal should not be to develop roles for every person at the company or organization.  The goal is provide the most role value by locating access right combinations that cover the majority of individuals.  Implement these effective roles quickly.  Address the exception or difficult to quantify roles later (or when possible).  For example: CEO is not a role, it is a unique job function or more accurately an “exception role”.
  • Phased approach – It has been my experience that role implementation encompassing the entire organization often fails due to the time and complexity required to complete.  Political and/or procedural roadblocks appear, addition of access endpoints and role function or purpose questions occur.  You should implement roles across focused areas of the company or organization where goals are well understood and attainable.

Questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

Tags: , , , , , , , , , , ,
Posted in Aveksa, Best Practices, CA, CA Role & Compliance Manager (RCM), Novell Role Based Provisioning, Oracle Identity Analytics, Oracle Role Manager, RBAC, Role Management, SailPoint, Vaau | No Comments »

CA Role & Compliance Manager (RCM) Automation using .SBT files

Tuesday, April 5th, 2011

***NOTE: As with all Tips and Tricks we provide on the IDMWorks blog, use the following AT YOUR OWN RISK.  We do not guarantee this will work in your environment and make no warranties***

Most tasks using CA RCM can be automated by using a simple batch language.  The advantages of using this automation is:

  • Reproducing imports, filters, merges, and enhancements of data that would executed multiple times manually.
  • Eliminating errors in data manipulation that would normally occur when conducted manually.
  • Reducing the time it takes manipulate RCM data for use.

The RCM documentation is rather lacking as to the commands that are available to use for RCM automation and I hope this document will provide assistance and information of .SBT file commands and use.  The batch files can be run in two methods; directly by executing the batch command from the DM utility or by creating a batch control file that can execute multiple batch files.  The advantage of using a batch control file (IMHO) allows flexibility in:

  • Determining which utility will be used to run the batch file, which is useful when different versions of the DM utility process the commands differently (TSS and RACF imports work on 12.5 SP1).
  • Controlling log and error output from the batch runs,
  • Breaking the RCM automated tasks into steps for ease of maintenance and execution.
  • Manipulation of the data files pre or post batch execution.

Here is an example of batch control .CMD file that I use (remove the .RENAME)

Here are the .SBT files that are controlled, the following automated RCM tasks are demonstrated within the examples:

  • Import from TSS
  • Enrich User Database
  • Filter configuration
  • Import from Active Directory
  • Merge configuration
  • Trim configuration

Questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

Tags: , , , ,
Posted in CA, CA Role & Compliance Manager (RCM), RBAC, Tips & Tricks | 2 Comments »

CA Role & Compliance Manager (RCM) Security and the eurekify.cfg

Friday, April 1st, 2011

***NOTE: As with all Tips and Tricks we provide on the IDMWorks blog, use the following AT YOUR OWN RISK.  We do not guarantee this will work in your environment and make no warranties***

The RCM security model and how to use it are (IMHO) not covered well in the documentation.  WebPortal users and their rights (and roles) are maintained in the eurekify.cfg file, which can be loaded from either the DM or DNA utility.  For safety reasons before I modify this file I save it locally, modify a copy of it and verify my changes to be certain that changes made are saved in the database.  A restart of RCM WebPortal is recommended to ensure changes made to users and their rights are acted upon by the RCM WebPortal.

One of the RCM WebPortal security items that I have found lacking was the ability to selectively limit or grant access to areas of the RCM Portal more granular than just a whole menu item.  For example, perhaps you want a user or a group of users to have access to specific report or administration activity.  Without modifications to the RCM security configuration your only option is to have access to all or none of the functions. To assist with this I have created the add-on RCM_eurekify_resources.rdb. This contains all of the RCM 12.5 SP3 WebPortal menu options.  With these added you can create roles of access to different RCM WebPortal menu options.

To use, complete the following steps:

  1. Download your current eurekify.cfg, .rdb, and .udb from the database
  2. Using a text editor (notepad) add the RCM_eurekify_resources.rdb to the end of your .rdb file
  3. Using DM or DNA add new roles and assign them to the appropriate users and your new portal resources as wanted.  (Note:  you will need to remove the existing {menu}.* options from your user roles)
  4. Save the eurekify.cfg (with and overwrite of the .rdb) to the database
  5. Restart the RCM WebPortal

Questions, comments or concerns?  Feel free to reach out to us at IDMWorks.


Tags: , , ,
Posted in CA, CA Role & Compliance Manager (RCM), Tips & Tricks | No Comments »

CA Role and Compliance Manager (RCM) 101

Tuesday, March 29th, 2011

Role and Compliance Manager (CA RCM)

Introduction to Role and Compliance Manager

CA’s Role and Compliance Manager (RCM) is a product designed to accomplish two core tasks for Role Based Access Control (RBAC):

  1. Locate, design, and model user access roles based upon user characteristics or patterns.
  2. Provide a Web portal for certifying (attesting) user access to resources.

RCM accomplishes this by importing data from endpoints or data sources such as Microsoft’s Active Directory, RACF (IBM Mainframe) or TSS (Top Secret) among others.  RCM divides the imported data into three categories; users, roles and resources.  User data contains items such as job titles, organization, and a unique user identifier.  The roles contain the association of users to resources such as windows groups (or maybe not) or mainframe resource profiles.  Resources are what the user has access to such as data sets, windows groups (or maybe not).   The RCM tools provide easy to use functions to locate roles, creation of subset configurations (filters), enhancement of user data (such as adding email address to users), displaying resources a users has or which users have access to a resource, and much more.  This data is than provided to the Web portal where certifications of users access to resources and role certification can be conducted.

RCM Deployment Requirements

The CA RCM GUI utilities are Windows based and can be deployed on almost any Windows version (W95, W2003, W2008).  Oracle or MS SQL server (MSDE is acceptable) is needed.  The Web portal uses the JBOSS Java application server.  A dual core Windows server with 4Gb of memory and 160Gb of disk will handle both the RCM client and portal requirements.  I prefer to use the windows platform exclusively as the use of the RCM GUI tools (DM and DNA) are windows exclusive.

Installation

Installation is quick and relatively painless.  A couple of pre-requisite software packages must be installed (JAVA JDK, MSXML, VC++ redistributable, .NET Framework, SQL Client).  Four databases are used on the SQL server, post configuration of JAVA memory, the JBOSS service, SSL certificates, and workflow imports are needed.  The installation can easily accomplished in less than one day with a good integration document.

Entries to follow:

  • RCM Automation using .SBT files

Other items to follow:

  • RCM Security and the eurekify.cfg
  • Export of RCM data to CA IdM

Questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

Tags: , , , ,
Posted in CA, CA Role & Compliance Manager (RCM), RBAC, Role Management | No Comments »

Provisioning to Active Directory with SailPoint (using SSL)

Tuesday, March 22nd, 2011

***NOTE: As with all Tips and Tricks we provide on the IDMWorks blog, use the following AT YOUR OWN RISK.  We do not guarantee this will work in your environment and make no warranties***

SailPoint’s new provisioning engine allows you to create, modify, and delete user accounts on various applications in conjunction with the Lifecycle Request Manager component of SailPoint.  The actual provisioning is done using the Tivoli Directory Integrator (TDI) product.

Provisioning to most applications is a relatively simple setup that consists of developing or importing the Connector and Assemblyline code and modifying the connection parameters to point to the correct application for the given environment.  SailPoint then calls the provisioning plan, which sends a JSON command to TDI which in turn provisions the account.

Provisioning to Active Directory (AD) is a little more complicated.  To create an active AD user with a password, TDI must connect to AD using SSL.  The setup to configure TDI to provision using SSL for AD is below.

Note: The instructions are written for a Windows 2008 server but would be similar if TDI were installed on another platform.

Prerequisites: A working TDI install with the Active Directory AssemblyLine and Connector imported.  These files can be obtained from SailPoint or can be custom written.

  1. Retrieve the CA certificate for the Domain controller
  2. On the TDI server, create or find a folder for the certificate and keystore (ex. D:\TDI_Store)
  3. Copy the CA Certificate to that folder
  4. Open a command prompt and navigate to the following %TDI Install DIR%\V7.0\jvm\jre\bin folder.
    • Example path: C:\Program Files\ibm\TDI\V7.0\jvm\jre\bin
  5. Enter the following command to create a keystore and import the AD certificate: 
    • keytool –import  –file “D:\TDI_Store\myservercert.cer”
–keystore “D:\TDI_Store\keystore.jks” –storepass Password1 –alias TDI_CA
  6. When prompted to trust the certificate, type yes and hit enter
  7. Verify the keystore was created and the certificate was imported by entering the following command: 
    • keytool –list –keystore “D:\TDI_Store\keystore.jks” –storepass Password1
  8. Export the default key from TDI by entering the following command: 
    • keytool –export –alias server –file tdiServerApi.cer
–keystore “C:\Users\admin\Documents\TDI\testserver.jks”
    • Note: The path to the testserver.jks corresponds to the user who setup the TDI server and create the server instance in TDI
  9. Enter the following command to import the TDI certificate: 
    • keytool –import  –file “D:\TDI_Store\testServerApi.cer”
–keystore “D:\TDI_Store\keystore.jks”
-storepass Password1 –alias TDI_CA_Default
  10. Edit the %TDI Install DIR%\V7.0\etc\global.properties file and change the items marked in red.
    1. ## server authentication
      javax.net.ssl.trustStore=D:\TDI_Store\keystore.jks
      {protect}-javax.net.ssl.trustStorePassword= Password1
      javax.net.ssl.trustStoreType=jks 

      ## client authentication
      javax.net.ssl.keyStore=D:\TDI_Store\keystore.jks
      {protect}-javax.net.ssl.keyStorePassword=Password1
      javax.net.ssl.keyStoreType=jks

    2. Example path: C:\Program Files\ibm\TDI\V7.0\etc\global.properties file
  11. Edit the %TDI Install DIR%\V7.0\etc\solutions.properties file and change the items marked in red.
    • # server authentication
      javax.net.ssl.trustStore=D:\TDI_Store\keystore.jks
      {protect}-javax.net.ssl.trustStorePassword= Password1
      javax.net.ssl.trustStoreType=jks
  12. Restart the TDI Configuration Editor
  13. Open the ActiveDirectory Connector
  14. Under the connection tab, change the following settings marked in red:
    • LDAP URL: ldap://mydomain.com:636
      Use SSL: Checked
      Auto Map AD Password: Checked
  15. Open the ActiveDirectory Assemblyline
  16. Make sure the userAccountControl field is being set to 512
  17. Restart the TDI server

Once this setup is complete, the environment is ready to provision to Active Directory using SSL.

Tags: , , , , ,
Posted in RBAC, Role Management, SailPoint, Tips & Tricks | No Comments »

The Do’s and Do Not’s of Role Management & Mining with Aveksa

Sunday, January 2nd, 2011

My last blog post about Role Based Access Control (RBAC) had to do with Role Mining specifically around techniques used in larger firms.

Recently, I’ve been working with Aveksa Compliance Manager (ACM) to develop roles for an up-coming certification and I have a few thoughts to share:

  1. Have a good understanding of your data, or find somebody that does. ACM gives you so much flexibility that unless you have a firm grasp on your data, you will not chose the right path.
  2. ACM breaks down roles into three distinct categories
    • Global Roles
    • Business Roles
    • Technical Roles

    DRAW out how you want these to be used first (see recommendations below).

  3. Configure ACM to work within the constraints developed in Step #2. (Roles -> Configuration).  This interface will allow you to configure Global, Business and Technical Roles and their membership constraints.

Now that you have made sense of your data and configured ACM to work within the boundaries of your Role Model, you can start creating or generating roles!

As I indicated above, I have some recommendations for you (not in any particular order):

  • Group collected entitlements into Technical Roles. DO NOT add members to your Technical Roles.
  • Create a Technical Role for any entitlement that you want to manage separately.  In other words, if you want to create a Technical Role for Active Directory Administrators, great, but if you want to manage Schema Admins and Domain Admins separately then these should be in different Roles.
  • Users will request access using the Business Role Name, so create Business Roles using names that make sense to Business users.
  • Along those same lines, don’t rely on your glossary to make up for your cryptic naming conventions.
  • Create a customer User View (Requests -> Configuration -> User Views) which lists all Business Roles when users request access.
  • When role mining, DO NOT create roles based on an attribute (say Department) for a large set of data without testing with a few departments first as roles can only be deleted one at a time!
  • Backup your database before you do any of this (this applies to all vendor tools btw, you will thank me for this later).

There’s probably 50 other things that I have learned in my RBAC travels; I’d love to share them with you and ensure that your ACM project is successful.  Don’t hesitate to give us a call here at IDMWorks, the Identity (and RBAC) Professionals!

Tags: , , , , ,
Posted in Aveksa, Best Practices, RBAC, Role Management | 1 Comment »

The Case for Access Governance

Thursday, September 30th, 2010

Well, if you are a CISO, CRO, CCO, CFO, CTO, a Business Manager, the VP of Enterprise Security, the VP of Internal Audit or in the IT Governance Audit department YOU DO………

Here are just a few of the reasons WHY

The CFO concentrates on expenditure….. As CFO you will want to keep the internal and external audit costs to a minimum as well as making sure that the finance department is compliant with regulations.

The CTO has to focus on the overall management of IT… As CTO you don’t want to worry about access rights and policies. You want an appropriate system to manage that for you.

The Business Manager is just that, all about the business…As part of the Business management team you want to do your job efficiently and profitably by making sure that users get the correct permissions and that the certification process is easy for you to understand without wasting your valuable time.

As for the rest of the illustrious cast, you all want to achieve sustainable audit worthy compliance processes that are effective in minimizing costs and exposure to business risk with timely, accurate delivery of appropriate access to users.

OK so that’s the who needs section and why you need it……now for some key reasons that may influence your decision to purchase and implement an access governance solution across your enterprise.

  • Are you facing an upcoming audit?
  • Do you have Audit issues related to access (SOX 404 segregation of duties and privileged account access issues – access risks that create GLBA/Basel/Solvency violations)?
  • Do you need to contain or reduce the costs of compliance?
  • Do you want to  implement enterprise roles to simplify and streamline the access request and delivery process?
  • Do you have a complex manual approach for access review and certification that uses multiple spreadsheets and is labor intensive?
  • Have you  experienced a data loss or a negative impact on the business due to misuse of access?

So what’s the next step?

If you realize that you are facing one or more of the above challenges may I respectfully suggest that you contact IDMWORKS to work out the finer details. We have a dedicated team of Identity and Access Management  professionals who will provide full program management services to incorporate new process, technology and functionality, ensuring success throughout the project lifecycle.

And the step after?

So now that you have recognized that there may be some issues that need addressing it’s time to think about product. IDMWORKS is ideally positioned to guide you through that selection and deploy the solution on your behalf.

.

Tags: , , , ,
Posted in Aveksa, GRC, Role Management, SailPoint | 1 Comment »

The truth about Roles, what people won’t tell you about RBAC

Monday, August 2nd, 2010

I have been at three separate companies as of late  that all strive to have the “perfect role model” for their enterprise. This desire is usually coupled with the desire to have some irrational number of roles to show that their role model was successful.

<Sidebar> Let’s say your company has 100,000 people worldwide, how on earth could you believe that you’re going to end up with 10 roles?

The answer to the number of roles is generally a product of how you want to create enterprise roles (this includes Business and/or IT roles). There are few options when it comes to designing roles, to list a few:

  1. Bottom-up, Top-down and Intersection Analysis (yawn, that’s so 2009)… and the result being a set of IT roles that map to resources, and business roles that map to the IT roles.
  2. Allow Supervisors to control # of roles, they decide what goes in their roles, and your systems make sure that they haven’t put any “toxic combinations” in their roles.
  3. Use #1 & #2 with a standard set of entitlements that everybody gets based on some organizational data.
  4. Allow a product to analyze your data and suggest candidate roles.

(All of these mean nothing unless your roles are “in-context”… to be covered in my next post.)

Now comes the part where I give my prescriptive advice on which of the 4 options to use. The answer: RBAC is art, not science, you should try all of the above, at least see if they pass the litmus test for your organization (better yet, call IDMWorks and we can help you figure it out).

Once you’ve figured out what direction you are going with roles, the next step is to stuff all of that in a product. Might I suggest Aveksa as it is the one of the best products in the industry, and use it to manage your roles, entitlements, segregation of duties rules and certifications.

Tags: , , , , , ,
Posted in Aveksa, Governance, RBAC | No Comments »

« Older Entries