Archive for the ‘RBAC’ Category
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: ABAC, Access Control, Attribute Based Access Control, extensible access control markup language, RAdAC, RBAC, Risk adaptive access control, Role Based Access Control, Rossin, SAML, secure access markup language, Todd, Todd Rossin, XACML
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 »
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:
+ 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”
+ 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: Aveksa, Bridgestream, CA Role and Compliance Manager, Oracle Identity Analytics, Oracle Role Manager, RBAC, RBACx, RCM, Role Based Access Control, Role Management, SailPoint, Vaau
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 »
Monday, June 27th, 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***
A recent install of Novell’s RBPM product has led me to remember that documentation often lags behind product development. There are a handful of reasons for this, the main being that when product is being actively developed, the feature set is not fully decided upon. So documenting the current state is many times an exercise in futility as the features may change very rapidly. T hus documentation is always an after-thought. The last task to be performed.
So without further ado, here are some observations. Specifically with regards to using WebSphere for web services.
1. AIX is not a supported platform for RBPM. Initially, the IDM 4.0 documentation stated that AIX was a supported platform. We had attempted the install but it never worked and discussions with Novell indicated that AIX was never intended to be a platform option for this version of IDM. It was subsequently removed from documentation in the IDM 4.0.1 release.
2. The Java environment variables are very strict. The version of Java that IBM packages with WebSphere 7 is the correct version, IBM J9 VM (build 2.4 J2RE 1.6.0) with Fix Pack 7 or higher. However, there is a step in the documentation that mentions you must apply the unrestricted policy files to JAVA_HOME/jre/lib/security. Failure to do so, results in the master key not being generated as the key size is not the proper size. REMEMBER THIS! This is very difficult to troubleshoot after the fact.
3. WebSphere uses shared libraries to incorporate jar files with web services. There are several setup steps in the documentation but there are some slight omissions. The java class, commons-logging.jar, is not packaged with the install and must be downloaded manually. This is noted in the documentation, however the additional classes of antlr.jar and jaxb-impl.jar are also missing and must be manually downloaded as well. A simple omission that can cause a great deal of hair pulling and teeth gnashing.
Hopefully these observations prevent anyone from committing a mistake. Good luck with your future installs.
Questions, comments or concerns? Feel free to reach out to us at IDMWorks.
Tags: Novell Identity Manager, Novell IDM WebSphere RBPM, RBPM, Role Based Provisioning Module
Posted in Novell, Novell Identity Manager, Novell Role Based Provisioning, RBAC, Role Management, Tips & Tricks | No Comments »
Thursday, May 26th, 2011
What is ABAC?
Attribute Based Access Control is an effort to shift the paradigm of granting resource access to a specific user to granting access based on the value of a user’s attributes. While user authentication is still required the access is no longer granted via a specific ACL. Instead at the point of authentication a decision is made based on the value of specific attributes whether or not access should be granted.
This approach significantly decreases the administration required to maintain data security. It also ensures that data is available real time to those who need it and are authorized to view/use it. No longer are provisioning request required in order to gain access to the data since access is evaluated and granted real time.
ABAC provides particular advantages when it is deployed in a Federated environment. Access is determined by the agreement between the two entities (business, organizations, governments, etc…) and then is enforced by the Policy Enforcement Point (PEP) at the time of access. Each entity maintains autonomous control of their identities.
For the public and private sector, the policies, the attributes, and metadata need to be defined to ensure seamless operation and protect information assets. This allows the enterprise to leverage attributes, metadata, and digital policies to secure access to resources in a flexible and robust decision and enforcement mechanism. ABAC enables the transition away from access control based solely on identity through evaluating and enforcing policies by leveraging enterprise sources of access control policies, attributes, and data in support of dynamic operating environments.
Why ABAC Matters
ABAC can facilitate secure information sharing by providing a greater emphasis on leveraging policies, attributes, and metadata to allow access to information in a controlled manner. Think RBAC (role Based Access Control) down to a fine-grained level through access control decisions and enforcement with interfaces for certificate validation, policy retrieval, and attribute retrieval.
Using ABAC, digital policies are defined and managed by policy administrators to protect specific resources. By doing so the decision and enforcement rules can be removed from the systems administrator layer of the enterprise and into the control and governance branch of enterprise.
The policies can then be derived from compliance and information assurance regulations defined by HIPAA, Sarbanes-Oxley, FERC, HSPDs, etc. ABAC thus enables a flexible means of securely sharing and protecting information through the enforcement of policies applicable to specific resources.
Access to information will then be governed by policies that can be rapidly created, modified, and consumed by IT systems. The policies will define the rules and conditions under which someone is authorized for access by using user characteristics, or attributes, and resource characteristics, or metadata, as opposed to membership to a resource ACL.
ABAC Components:
| Component |
Description |
| Policy Enforcement Point (PEP) |
The PEP, similar to a Policy Agent or Webgate (for you SSO folks out there) intercepts user requests to resources and enforces access control decisions. The PEP’s main function is to grant or deny user access to the resource and enforce workflow obligations or constraints on the interaction. The PEP can also support user authentication, by checking the status of a user’s credentials and verifying authentication assertions. |
| Policy Decision Service (PDS)
Or
Policy Decision Point (PDP) |
The primary function of the PDS is to render an access control decision based on a policy. This is calculated through access control decisions based on the security context of the interaction between the user and the application or resource being protected. The security context is comprised of access control parameters including policies, user attributes, resource metadata, and environment attributes. The PDS can retrieve the access control parameters from sources at various levels of the enterprise to render a decision. |
| Policy Service (PS) |
The PS retrieves access control policies from a policy store. Typically, the PDS will use the PS to request the applicable policies pertaining to the security context of a transaction. Rules typically are utilized in a collection, known as Policies to be called up by the PS. If you can build a basic IF, THEN, ELSE statement then you can build rules for your policies. |
| Attribute Service (AS) |
The AS retrieves user information from an attribute store. The AS retrieves user information associated with a user from variety of authoritative identity stores including, but not limited to, LDAP and database stores. |
ABAC Basic Flow (as in very basic, does not include Certificate Verification Services):
Basic ABAC Flow
The only thing I left out is a PAP, a Policy Administration Point. Essentially an interface to create and maintain Policies. This can reside on a separate server or client machine depending on vendor. In certain cases, the PAP is nothing more than an XML editor.
Questions, comments or concerns are always welcome. Feel free to reach out to us at IDMWorks.
Tags: ABAC, AS, Attribute Based Access Control, Attribute Service, Attribute Store, Axiomatics, Bitkoo, Cisco, Epok, Jericho Systems, Keystone, Layer 7, NextLabs, Oracle Entitlements Server, PAP, PBAC, PDP, PDS, PEP, Pericore, Policy Based Access Control, Policy Decision Point, Policy Decision Service, Policy Enforcement Point, Policy Service, Policy Store, PS, Quest, Rossin, Siemens, Todd, Todd Rossin, Vordel, XACML
Posted in Attribute Based Access Control (ABAC), RBAC, XACML | No Comments »
Thursday, April 21st, 2011
Accomplishing synchronization or provisioning of users, resources and/or roles from CA RCM into CA IdM involves a complicated configuration setup for RCM and IdM and understanding what requirements and limitations exist.
Here is a short list of items that should be considered:
1. CA RCM to IdM integration is predicated on the fact that users, resources and or roles are imported first.
2. Configuration of the CA IdM resource connector is a requirement for managing users, resources and roles at the managed IdM endpoints.
3. Not all IdM endpoints have a resource connector that can be configured. The following chart shows what is supported for release 12.5 and as RCM and IdM versions are released this list will grow:
| Endpoint |
Version |
Additional comments |
| Active Directory (ADS) |
Active Directory 2003 |
Customizable Connector method and Legacy method available |
| UNIX (ETC) |
Red Hat 5.1 |
Customizable Connector method and Legacy method available |
| MS SQL Server (SQL) |
MS SQL 2005 SP3 |
Customizable Connector method and Legacy method available |
| Generic LDAP (LDA) |
CA eTrust Directory 8.1 |
Customizable Connector method and Legacy method available |
| Windows NT (N16) |
Windows 2003 SP2 |
Customizable Connector method and Legacy method available |
| Oracle Database (ORA) |
Oracle 11g |
Customizable Connector method |
| OS400 (AS4) |
OS400 V5 R2 |
Customizable Connector method only available |
| SAP (SAP) |
ECC 6.0 |
Legacy method only available |
| DB2 Database (DB2) |
DB2 9.1 (UDB) |
Legacy method only available |
4. The defaultMapping.xml file provides the mapping of RCM attributes to IdM attributes. It has been my experience that the list of attributes on the IdM side is fixed and substitutes likely will not work.
5. At least one endpoint must be configured in the endpointTypeMapping.xml file.
There are plenty of other considerations, configurations and methods to make the import/export successful (look for future blogs on the subject). The grapevine has indicated that major changes involving more integration between the products will occur with the release of RCM 12.5 SP4 coupled with IdM 12.5 SP7.
As usual, Questions, comments or concerns? Feel free to reach out to us at IDMWorks.
Tags: CA IdM, CA RCM, Endpoints, Integration, Provisioning, Role and Compliance Manager
Posted in Best Practices, CA, CA Identity Manager, CA Role & Compliance Manager (RCM), Identity Management, RBAC | 1 Comment »
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: CA Role & Compliance Manager; RCM, RBAC, RCM, Role Based Access Control, Role Management
Posted in CA, CA Role & Compliance Manager (RCM), RBAC, Tips & Tricks | 2 Comments »
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):
- Locate, design, and model user access roles based upon user characteristics or patterns.
- 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: CA, Compliance, Identity Management, RBAC, RCM
Posted in CA, CA Role & Compliance Manager (RCM), RBAC, Role Management | No Comments »
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.
- Retrieve the CA certificate for the Domain controller
- On the TDI server, create or find a folder for the certificate and keystore (ex. D:\TDI_Store)
- Copy the CA Certificate to that folder
- 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
- Enter the following command to create a keystore and import the AD certificate:
- When prompted to trust the certificate, type yes and hit enter
- Verify the keystore was created and the certificate was imported by entering the following command:
- Export the default key from TDI by entering the following command:
- Enter the following command to import the TDI certificate:
- Edit the %TDI Install DIR%\V7.0\etc\global.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
## client authentication
javax.net.ssl.keyStore=D:\TDI_Store\keystore.jks
{protect}-javax.net.ssl.keyStorePassword=Password1
javax.net.ssl.keyStoreType=jks
- Example path: C:\Program Files\ibm\TDI\V7.0\etc\global.properties file
- 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
- Restart the TDI Configuration Editor
- Open the ActiveDirectory Connector
- 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
- Open the ActiveDirectory Assemblyline
- Make sure the userAccountControl field is being set to 512
- Restart the TDI server
Once this setup is complete, the environment is ready to provision to Active Directory using SSL.
Tags: JSON, RBAC, Role Based Access Control, SailPoint, TDI, Tivoli Directory Integrator
Posted in RBAC, Role Management, SailPoint, Tips & Tricks | No Comments »
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:
- 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.
- 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).
- 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: Aveksa, Paul, Paul Bedi, RBAC, Role Management, Roles
Posted in Aveksa, Best Practices, RBAC, Role Management | 1 Comment »
Monday, November 15th, 2010
Interestingly enough I have been asked many times as to what exactly IDMWorks is and what it is that we do (and I don’t just mean the wife and kids). As such it seems time to do the quasi-annual blog sales pitch. I think most of our readers have an idea what we do and have perused the site to better inform themselves but there are some that don’t tread any farther than this here blog. So in keeping with the simplicity of blogvertising I present you IDMWorks.
Subject: Enterprise Identity & Access Management and Governance, Risk & Compliance
You may be aware of many of the issues organizations are facing today around the various challenges and aspects of Identity Management and Information Security.
At IDMWORKS we understand the problems that many of you are facing and are positioned to help. IDMWORKS is a vendor agnostic, Identity Management, Access Management, and Governance, Risk and Compliance Management Consultancy. We have consultants and engineers across the United States and North America that specialize helping clients with most aspects of Identity, Access Management, and GRC issues, including the following:
- Identity and Access Management technology evaluations and POCs
- Identity Management strategy creation, Integration and Deployment
- Identity Management / IT Security Technologies Assessment, Evaluation, and Planning
- Identity Management / IT Security Education
- Pre & Post Identity Management project Support Services
- Identity Federation
- PCI Compliance
- Governance, Risk and Compliance Management , Provisioning
- Single Sign-on and Web Access management
- Data Loss Prevention
IDMWORKS has been built upon the skills and experience of dedicated IDM professionals and specialist with a customer base that includes Government, Healthcare, Education, Financial Services, Energy, Manufacturing and Retail clients.
IDMWORKS has experience with the integration and implementation of the market leading Identity & Access Management, and GRC solutions and technologies – CA, Oracle/Sun, Novell, IBM, Aveksa, Citrix, Passlogix, and Sailpoint, to name a few – and would welcome the opportunity to discuss your IT Security needs to determine how we can help.
We would like to offer you the opportunity to take advantage of an initial Identity Management, and Compliance Assessment. The results of the assessment will include recommendations on potential solutions to address your current Identity management and GRC related issues.
For further information or to arrange an initial consultation, contact IDMWorks to discuss how we can help with a solution to address your needs.
Tags: Access Management, Compliance, Governance, GRC, Identity Management, idmworks, PCI Compliance, Risk, Role Management, Rossin, Todd, Todd Rossin
Posted in Access Management, Aveksa, Best Practices, CA, CA Identity Manager, CA SiteMinder, Citrix, Citrix Password Manager, Citrix XenApp, Cloud Computing, Enterprise Single Sign On (ESSO), Governance, GRC, Identity Management, Identity Provisioning, Novell, Novell Access Manager, Novell Identity Manager, Oracle Access Manager, Oracle Fusion Middleware, Oracle Identity Manager, Oracle Role Manager, Password Management, PCI Compliance, RBAC, Risk & Compliance, Roadmap, Role Management, SailPoint, Security & Risk, Single Sign On (SSO), SOA, SRM, Sun Identity & Access Management, Sun Identity Manager | No Comments »
