empowerID to Present at KuppingerCole European Identity & Cloud Conference

Posted by Chris Hayes on Tue, Apr 28, 2015

 

empowerID is excited to announce that CEO Patrick Parker will present at the European Identity & Cloud Conference (EIC) hosted by KuppingerCole on May 5-8 at the Dolce BallhausForum Unterschleissheim in Munich, Germany.


Patrick's session entitled "How to Manage Authorizations in Cloud Services" takes place on Tuesday, May 5


Topics covered will include:

  • The race to transplant onsite infrastructure and applications to the Cloud
  • How to enable strong yet flexible control over authorization
  • How to approache the challenge of role and attribute-based authorization
  • Patrick will give an overview of the authorization capabilities offered by the Microsoft Azure and Amazon AWS platforms and include best practice suggestions.
empowerID was identified as an "Overall Leader" in the KuppingerCole Leadership Compass in 2014.  Click here for your copy of the latest KuppingerCole IAM/IAG Leadership Compass

Tags: Role Based Access Control (RBAC), RBAC, SAML

EmpowerID Named Overall Leader in IAM / IAG Suites

Posted by Patrick Parker on Thu, Feb 05, 2015

Rating graph

EmpowerID has been recognized as a three time leader in a recent KuppingerCole report evaluating Identity and Access Management (IAM) / Identity Access Governance (IAG) Product Suites.

The IAM/IAG Leadership Compass “focuses on complete IAM/IAG (Identity Access Management/Governance) suites that ideally cover all major areas of IAM/IAG as a fully integrated offering,” Martin Kuppinger wrote in the report.

KuppingerCole, a respected global analyst focused on Information Security, examined Identity and Access Management / Governance Suites for this report. They specifically evaluated products that are integrated solutions with a broader scope than single-purpose products. Martin Kuppinger concluded in the report, “With their Windows-based product they [EmpowerID] offer one of the best integrated IAM Suites. All components have been built by EmpowerID, allowing for tight integration into a well thought-out architecture. This integrated approach is a clear strength of EmpowerID."

To request an unabridged copy of the the KuppingerCole report on IAM/IAG Suites, please visit http://info.empowerid.com/download-the-free-kuppingercole-iam-suites-leadership-compass.

Tags: Role Based Access Control (RBAC), GRC, authentication, IAG, IAM, Group Management, Governance and Regulatory Compliance, Identity Management, Federation, User provisioning, Attestation, Separation of Duties, Identity and Access Management (IAM), Access Governance

SSO and Delegated Management Module for Office 365 Released

Posted by Patrick Parker on Fri, Sep 12, 2014

365 banner resized 600

Yesterday we announced the release of Office 365 Manager, a new module that enables organizations to extend their existing on-premise security and audit control model to the Microsoft Office 365 and Azure Active Directory Cloud. We have also released a new web site dedicated to information on Office 365 Manager. The new site is located at http://office365.empowerID.com.

We are seeing rapid adoption of Office 365 to reduce the cost of IT operations. Office 365, however, is presenting our customers with some security and management challenges because it offers only basic audit controls and a limited ability to delegate administrative tasks. Our new Office 365 Manager provides organizations with the first and only Identity and Access Management solution that applies existing security practices for on-premise Active Directory and Exchange to the management of Office 365 in the Cloud.

Office 365 Manager allows organizations to leverage the same secure delegation and flexible administration model that they use for their behind the firewall systems. It addresses a key shortcoming of Office 365 which runs on Azure Active Directory and lacks a hierarchical structure that forces the placement of all users, groups, mailboxes and contacts in a single location. By extending the existing structure of a customer’s on-premise Active Directory, LDAP, or HR system to Office 365, Office 365 Manager can securely delegate responsibilities by role, department, business unit and location.

With Office 365 Manager's Single Sign-On capabilities, your internal users can continue to use their existing Active Directory username and password when logging in to Outlook, OWA, Lync, and SharePoint after they have been migrated to the Office 365 cloud. External partners or customers can leverage Social Media logins, your own branded EmpowerID login, or even their remote corporate AD credentials.

Top 10 features and benefits of the new Office 365 Manager:

1.    Role-Based Delegated Administration to Reduce IT Staff Workload 
2.    Automated Provisioning and Sync for Better Productivity and Security 
3.    Dynamic Group Management for Improved Group Security 
4.    Single Sign-On for Ease of Use 
5.    Multi-Factor Authentication for Improved Access Security 
6.    Mobile Device Security (BYOD) To Properly Secure Mobile Device Access 
7.    Self-Service Password Management to Reduce Help Desk Workload 
8.    Shopping Cart Style Self-Service to Automate Request Fulfillment and Audit Tracking 
9.    Access Recertification and Audit Reporting For Better Access Governance 
10.     Mailbox and Folder Permission Audit, Management, and Self-Service for Improved Productivity and Governance

 

                                               Secure  Office 365  Today!

Tags: Single Sign-on (SSO), Role Based Access Control (RBAC), User provisioning, Office 365

The marriage of access governance and access control

Posted by Edward Killeen on Fri, Nov 01, 2013

marriage of access governance and access controlI might be splitting hairs but access governance and access control are different animals...yet different animals that belong to the same species.  I'm picturing a doberman dachsund mix, cute AND effective as a guard dog!

Most Identity & Access Management (IAM) projects seem to focus on one or the other and often end up with two products, one for access control and one providing access governance.  But why wouldn't you want one solution providing both aspects of access, looking forward and looking backward.

EmpowerID's Role Based Access Control (RBAC) engine secures resources, manages roles and permissions, manages Separation of Duties (SOD), and has a powerfule multi-tier attestation capability.  In addition to RBAC, EmpowerID also incorporates Attribute Based Access Control (ABAC) into its capabilities for finer grained permissions delivered at run-time.  Temporary Privileged Access (TPA) helps keep your organization following the principle of least privilege.

That is access control.  All of these permissions and roles are stored in the EmpowerID metadirectory and projected into other platforms (AD, UNIX) and applications (cloud and on-premise) to give a comprehensive access control platform for the entire enterprise.

And that is the key, it is stored centrally.  All access control for all connected systems and applications.  Sitting there in a comprehensive, scalable, secure metadirectory.  And within that same platform that is controlling all of this access are the access governance workflows.

Access governance comes in two flavors: audit-driven and business-driven.  Auditors usually want reports and stacks of paper detailing all of the SOD violations, the excess permissions, the compliance issues.  Business owners want the same thing but also want the ability to effect the change immediately to remedy an issue.

EmpowerID gives a 360 degree view of permissions to address this (and actually, auditors appreciate this too!):

  • Who is a member of a role and/or group
  • What resources does that role and/or group have access to
  • What users/roles/groups have access to a particular resource

So, you look at it from the user perspective, the role perspective, and the resource perspective.  At any point, with the business-driven access governance approach, the business owner can correct an issue, authorize an exception, or delegate the action.  EmpowerID's approval workflows can escalate anything and all of these actions are then reported for the audit-driven access governance.

The access governance is managed from within the exact same user interface as the access control which give a familiar look and feel and the workflows within a mouse click to fix them.

Access Governance and Access Control do not have to be separate.  Provide the auditor the tools for access governance, but fix the access issues as they happen, not once an auditor finds them.

Click me

Tags: Role Based Access Control (RBAC)

Active Directory group management....what about other groups?

Posted by Edward Killeen on Fri, Oct 18, 2013

I have a long history with Active Directory group management and as much as I fundamentally believe that roles are better for access control, sometimes you have to bite the bullet and use groups.  The reason is that some applications use groups, Microsoft loves groups, and it's a concept everyone gets.

active directory group managementThere are basically two types of group management: delegated group management and dynamic group management.  Each has its place. There is a third facet to group management where you manage resources and what groups have access to the resource but that is slightly out of scope of our discussion here.

In delegated group management, group owners are able to manage the membership of their groups and users are able to request membership in groups.  A helpful user interface is presented to make it easy for users to get themselves into groups.

Dynamic group management is all behind the scenes.  Based on what you know about your user(s) from any number of identity stores, you build rules that dynamically place users in the group.  For example, every user who is a manager in Marketing (based on title in Active Directory and department in HRIS) will be dynamically and automatically placed in the Marketing manager group.  Once they no long fit that equation (promotion or department change), they are removed from the group automatically.

There are two types of dynamic groups: hierarchies and standalone.  In a hierarchical group, you don't have to create each one, you set up the rules from the top.  For example, every department needs its own group, it would take forever to individually configure each, so you create a hiearchical dynamic group (like a family tree or org chart) that creates and manages membership for every department and title.  With EmpowerID, these attributes can be from any identity store.  Standalone are like the Marketing Manager example above.

This need for delegated and dynamic groups does not stop at Active Directory groups (distribution and security groups).  Within your organization you are going to have various flavor of LDAP groups, SharePoint groups, roles masquerading as groups within applications, as well as the AD groups.

Your solution needs to support both delegated and dynamic groups of all kinds.  EmpowerID does this with a highly scalable metadirectory (managing its own groups and roles) and highly configurable connectors that can project these groups into any of the types of systems and applications you need.

In fact, you can manage a role in EmpowerID that is projected as a group in LDAP or AD giving you the best of both worlds.  This flexibility gives you more options for managing groups with less configuration and work.

EmpowerID can easily help you manage all of your groups, not just AD, not just LDAP, not just SharePoint...it is a complete group management solution that promotes the benefits of role based access control without losing the inherent need for group management as well.

A picture is always worth a thousand words, schedule a personalized demonstration and see how to manage all of your groups quickly and easily.

Click me

Tags: Role Based Access Control (RBAC), Group Management

User provisioning software needs roles

Posted by Edward Killeen on Thu, Oct 17, 2013

user provisioning softwareI like to think that I am unique.  However, to my IT, security and identity teams, I am just a mix of sales, marketing, management and location roles.  Knowing those four things about me can generally define what system access I will need.

A properly built Identity & Access Management (IAM) infrastructure can determine which of these roles I am in dynamically based on attributes in my HRIS, Active Directory, and other identity stores.  For external users, the source of truth might be CRM or your supply chain identity store.  These attributes are everywhere and can easily be synchronized into a metadirectory like EmpowerID's that utilizes a hub and spoke model, giving you a full 360 degree view of all of your users' information.

Once you know everything about your users and the role(s) that they have, what are you going to do about it?  Provision user accounts!  Remember those four roles that define me?  Those also define what user accounts that I should have. 

My "person object" or "identity" in the metadirectory includes the role definitions and role based provisioning rules to provision these accounts.  It sees "sales manager in California" and knows that I need SalesForce, GoToMeeting, a soft phone and Dynamics AX accounts.  EmpowerID will provision these accounts and then link them to my "person object".  Once I no longer satisfy the conditions for having that role, my user accounts (not my identity) are de-provisioned.

Having a connector to each application allows the metadirectory to also inventory that application to determine if any changes are made natively.  If it finds a new GoToMeeting account that is not linked to an person object, it will evaluate "join rules" to join this account (or de-activate it if you want to discourage or deny native access).  If there is no person object to join it to, it will become an orphaned account and the appropriate admin will be notified.

This role based provisioning is exceptionally important for external users such as contractors or suppliers or customers.  All of these users are more temporal, coming and going more frequently.  If a supplier needs access to your Ariba procurement network, you want to give a lifecycle to that account, ensuring that somebody certifies or attests to the account.  Let's say for example that the procurement role needs to attest, perhaps you want to do a runtime check to see who the supplier's account manager is and only have them responsible.  This Attribute Based Access Control (ABAC) method keeps you from having too many roles while still giving fine grained permissions around either the initial approval or attestation of a new account.

user provisioning workflowAs you are designing these role based user provisioning rules, you are probably mapping them on a whiteboard.  EmpowerID's visual workflow platform actually allows you to drag and drop shapes (identity actions such as provision account, go for approval, etc) exactly as you are drawing it.  Though it is most likely more colorful and exciting in EmpowerID!

Don't get stuck with user provisioning that doesn't take into account who your users are.  And certainly don't get stuck with a limited level of roles and identity sources.  Because even though every user can be defined by their roles, they are still most likely a unique blend of multiple roles.  Your user provisioning process should reflect that.

Read how EmpowerID's unique RBAC and ABAC hybrid model gives you more finely grained control over all things roles: from authorization to authentication to provisioning.

Click me

Tags: Role Based Access Control (RBAC), User provisioning

Roles vs. Groups with Microsoft Dynamics AX

Posted by Edward Killeen on Thu, Oct 10, 2013

You can manage access to Microsoft Dynamics AX with Active Directory security groups.  But you can only get so far.

A manufacturing client of ours has very specific and extensive needs for Dynamics AX.  Of course, they need to provide access to employees but they also need to have dealers, suppliers and other partners to have access.  Once in Dynamics AX they need to take advantage of the internal roles to ensure that the right users have the right permissions.

roles or groups in dynamics AXSecurity groups seem like the best fit from 30,000 feet...both AD and Dynamics AX are part of the Microsoft stack.  Microsoft has set it up so that if you are in a specific security group for Dynamics AX , you can authenticate and use Dynamics AX.  But they stopped there, close but not close enough to actually use the solution for our client's needs.

Two things in our client's use case preclude them from using groups: the external users and the specific roles within Dynamics AX.  They have absolutely no interest in maintaining AD users for these external dealers and suppliers.  And they want to take full advantage of Dynamics AX and have different roles within it.  The whole idea is to be automated, not have to go in and manually assign permissions once a user has been put into a group.

So, what do you do?  EmpowerID.  A full IAM suite will give you the three components you need to manage Dynamics AX access correctly. 

You need a flexible connector that speaks to Dynamics AX using AIF.  Microsoft Dynamics AX Application Integration Framework (AIF) enables companies to integrate and communicate with external business processes and partners through the exchange of XML over various transport media. AIF enables both business-to-business and application-to-application integration scenarios.

EmpowerID's metadirectory gives you an identity store for your external users separate from Active Directory.  These users can then be provisioned into Dynamics AX using the connector and given the appropriate permissions and roles.  These roles and user lifecycles are managed in EmpowerID.

EmpowerID's RBAC engine gives a flexible and powerful polyarchical role structure.  You can manage your roles dynamically and map them to Dynamics AX, giving the exact permissions you need.  All role assignments and Separation of Duties (SOD) is managed in EmpowerID so you can attest, certify and automate all of the processes you need to manage access.

So, when do you use groups?  When you want to give vanilla roles to a set of users that are all in AD.

When do you use roles?  When you want to manage a diverse set of users with a diverse set of access permissions in Dynamics AX.  And when you want to automate it without dedicating a help desk person to managing it manually.

Most organizations using Dynamics AX have business, compliance and auditing requirements.  They are using it because they need to manage critical business processes and business data.  Not using roles to grant correct permissions seems to work against the investment they have made in Dynamics AX.

Schedule a demo of Roles in Dynamics AX

Tags: Role Based Access Control (RBAC), Group Management

Attestation and lifecycle in Identity Management

Posted by Edward Killeen on Tue, Oct 08, 2013

attestation and lifecycle in identity managementRemember your first day on the job at your company, you were given access to a few things, keys to the kingdom if you will.  A year later you were promoted, given new responsibilities and a few more of these "keys".  By the time you've been at a company for a few years, your "keychain" looks like one of those giant keyrings that a NY super has.

This illustrates why everything in Identity Management needs to have a lifecycle, a beginning and an end.  Obviously, a user has a lifecycle: hire date and fire date.  Their roles need a lifecycle based on what gives them that role (department, title, location).  Similarly, group memberships and existence need a lifecycle. 

Access to a resource needs a lifecycle.  Not just membership in the group or the group's existence, but the access of that role or group to a resource (file share, application, et cetera).  When you provision a user in an application like Google Apps, you want to periodically ensure that the user should still have that account.

Everything needs a lifecycle.

So, how do you manage that?  There are two primary methods, attestation and dynamic assignment.  And, just to invoke Inception, sometimes you may need to attest to the rules of dynamic assignment!

Let's start with attestation.  This is not only a good business practice, but required for all sorts of regulatory and compliance reasons.  The owner of an object or resource needs to periodically attest or certify that that resource should still exist; this could simply be responding to an email that yes, this resource should still exist and that the access levels are correct.

In addition to certifying that the object/resouce should still exist, all access needs to have a 360 degree view of its permissions.

User:  The manager of a user or an HR contact should periodically attest that the user still exists.  And attest that the user has the correct group/role memberships and correct application/resource

Role / Group:  This role and/or group has the correct membership.  This role and/or group has access to the correct resources.

Access to Resource:  This resource has the correct roles and/or groups granted access.

Attestation should allow for email responses, have a complete dashboard with that 360 degree view from the perspective of the user/member, role/group, and resource and give a flexible timeline for attestation based on the security level of the access.

A lot of this can be managed dynamically to reduce the number of attestations needed.  If you know that every manager in HR should have access to the 401K administration SharePoint site, just create a dynamic role that queries SAP HCM (or whatever HRIS you use) and places those users in the correct role or group.  You don't need to attest to the membership of the role or group, your user attestation will certify that the titles are correct and you are then guaranteed that the membership is correct.

With a metadirectory like EmpowerID, these attributes can be synchronized through any number of sources and updated every 5 minutes.  They dynamic memberships will be accurate and security will increase.

The same principle can then be applied to application access.  If you are managing roled dynamically, your provisioning and deprovisioning workflows can check role memberships and create/update/delete application accounts based on role based provisioning.  That HR Manager above moves over to Marketing?  Their role changes, the EmpowerID workflow will deprovision their account in SAP HCM and provision a HubSpot account for them!  Dynamically and automatically.

The key to all of this working is a cohesive Identity Management platform that allows you to map business process to identity processes.  Your metadirectory and RBAC engine and workflow platform all work together with a slick HTML5 user interface to give you all of the capabilities to make sure that the right users have the right access to the right resources.

See a demo of attestation in action!

Tags: Role Based Access Control (RBAC), Identity and Access Management (IAM)

RBAC with RBAR (Rights Based Approval Routing)

Posted by Edward Killeen on Thu, Oct 03, 2013

Identity & Access Management (IAM) is built on workflows -- a workflow is the sequence of actions that actually decide who a user is, what they can do, and to what can they do it.  I like Gartner's definition: "IAM ensures the right people get the right access to the right resources at the right time, enabling the right business outcomes."

All of those "right this" or "right that" is where it gets complicated.  Who can do what, how do you determine who has the rights to undertake a particular action in a workflow?  The RBAC model relies on roles (and ABAC to a lesser extent); based on what we know about a user's identity (department, title, location, business function, etc), we determine what their role is.  We then assign permissions to roles rather than to individual users.

Here's a great example: a doctor can access a patient's medical records.  Easy...we have two roles, doctor and patient.  Let's make it match the real world though, a doctor can only access a patient's medical records if that patient is under that doctor's care.  We can't make that many roles, so we add a run-time ABAC check to see if that particular patient is under that doctor's care and only grant access if that is true.  We do this with only two roles but use ABAC for finer granularity.  We have a whitepaper on the RBAC and ABAC hybrid model, please download it.

rights based access control approvalSo, that's how we define who has access.  But more often than not, there is an approval layer in the workflow.  We know that an admin role can create a new user but might need an HR approval before it happens.  A user can update their own phone number but their manager needs to approve it.  A user can join a distribution list but the group owners need to approve it.  It's a simple business control but can get complex.

And that's where Rights Based Approval Routing (RBAR) comes in.  When designing the workflow around users joining groups, you can't define a single role as the approver because there are many (IT admins, the group owner, your COO for example).  What you do is put in a "go for approval" shape and let RBAR handle it.

The RBAR approval shape basically says, "does the user requesting access have the right to do this?"  If the answer is yes, then, bam, it's approved.  If the answer is no, RBAR asks, "well then who does?" and goes to get that approval.

Let's use our group example, the user requests to join the party planning committee distribution group.  RBAR notes that the user is not an owner or an admin so it first attempts to send an approval request to the owners.  If there are owners, that approval message is in their hands.  If there are no owners (you remember from The Office how often that committee changed), then RBAR looks up who else can do it...IT admins and the COO...and sends it to them for approval.

Without the IAM architect having to do any of the work for this multi-faceted approval methodology, RBAR has made a robust and easy method of implementing Role Based Access Control (RBAC) and getting more out of less resources.  Check out a more technical explanation of how RBAR fits into IAM workflow.

 Click me

Tags: Role Based Access Control (RBAC)

SharePoint permissions dynamically by role

Posted by Edward Killeen on Thu, May 23, 2013

SharePoint permissions do not have to be managed with SharePoint groups, those lonely unmanaged completely removed from the rest of the enterprise collections of users.  SharePoint has evolved to first accept Active Directory groups for permissions and now to accept roles via a claims provider.

Claims providers created in SharePoint can be used for adding claims to the security tokens of users when configuring permissions on secure objects like lists, sites, items and documents.  When EmpowerID is the claims provider, it provides its dynamic polyarchical roles as a selection in the SharePoint People Picker.

How is this useful?  Well, it's a lot easier to manage EmpowerID role memberships than SharePoint or even AD groups.  EmpowerID roles can be managed dynamically by any attribute in any connected identity store (Active Directory, HR, CRM, ERP).  Role locations as well can be mapped from any connected application so a user in the London OU in Active Directory will be mapped to the London role automatically.

By having management roles (the user's job(s)) and location in separate trees, you can define permissions very granularly.  For example, you may only want IT managers in London to have access to the SharePoint site to review IT tasks in London.  You simply pick from the two trees to get IT Admins in London.

Manage SharePoint permissions with roles

You can even add a runtime decision by incorporating Attribute Based Access Control (ABAC) into the equation if you want to check your timecard system to only allow on-duty IT Admins to have access!

The advantage to all of this is that user's permissions are not static.  Conservative estimates say that internal turnover is about 20% per year, meaning that 1 in 5 users will change jobs.  Think of the last time you updated a SharePoint group....it is certainly not that often.  Roles, however, are dynamic, reading from attributes that flow from within HR or any other authoritative source.  If that IT Admin makes the mistake of starting in sales, she will automatically have her IT admin role revoked and new sales role(s) invoked.  Permissions will change without IT having to lift a finger.

Check out our whitepaper on dynamic roles or schedule a demonstration of EmpowerID and see how it can increase your security in SharePoint without having to mess around with SharePoint groups!

Schedule demo of SharePoint Permissions Mgmt

Tags: Role Based Access Control (RBAC), SharePoint