Archive for the ‘Access Management’ Category

Oracle Access Manager (OAM) 11g Auditing Tips

Monday, January 30th, 2012

***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***

Let’s say you want to enable auditing with Oracle Access Manager 11g so you can see successful (and failed) authentication and authorization events. You will commonly see documentation telling you to simply change the Audit Policy settings for your Weblogic domain in Enterprise Manager (see below) to enable OAM auditing.

Oracle Enterprise Manager - Audit Policy

There’s actually an additional step that you will need to take to full enable the auditing. Login to the OAM Console and navigate to the System Configuration tab. Choose Common Settings, and under Audit Configuration (see below) you will see an option to enable a Filter. Note that the Filter Preset option defaults to Low, so you’ll need to change it to All to see authentication and authorization events. One more important thing to do is remove any users from the list, otherwise you will only capture events for those users listed.

OAM Console - Audit Configuration

Note that you’ll have to restart after you make the changed in Enterprise Manager. After the restart, you will find audit events in the IAU_BASE table, and the BI Publisher OAM reports. Remember, you can find the OAM reports in <Oracle_Home>/oam/server/reports/oam_audit_reports_11_1_1_3_0.zip.

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

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.

Your IAM Toolset: the NVD Database

Monday, August 29th, 2011

Being in technical field it seems the TLAs (Three Letter Acronyms) and FLAs (Four Letter Acronyms) abound. But at times knowing about a few of them may provide key information we can all use to protect our customers.

Such is the case with the NVD (National Vulnerability Database)

First off, the NVD is hosted on the NIST.gov site. This database contains information about software or programming that can either create or leave open vulnerabilities. For example, if you type IDM on the search bar, 57 entries come back.  These include vulnerabilities in IDM apps including Novell and Sun IdM (btw, I only picked these two as they are on the first set of returned entries). If you open one of these vulnerabilities the NVD has information on what causes it, what damages it could do and most improtantlyhow to remediate it.

You can search by product or vendor name to narrow in on the entries that might be of concern. Some of the newer ones have just been reported and might not have a solution yet. Of course you can check with support at the company whose software has a concern.

So I’d recommend taking a few minutes to explore this database and the information that is availableand add this site to your IDM toolset.

Have a tool we should profile and/or add to the blog? Feel free to sound off below or reach out to us at IDMWorks.

Avatier Identity Management Suite (AIMS) Overview

Monday, August 29th, 2011

The Product: Avatier Identity Management Suite (AIMS)

The Review:

Install

The installation of the Avatier Identity Management Suite (AIMS) was one of the more straight forward processes we have encountered and only took about 15 minutes to complete. The product itself installs on a Windows 2008 32/64 bit server (for version 7 and earlier) and for version 8  installs on a Windows server 2008 R2 64 bit.  AIMS is GUI driven and offers a branding interface that allows the customer to modify text or any of the graphics that appear on those screens without the need for custom programming or scripting. The product offers a range of connectors as many of the vendor IdM applications do and as is to be expected, with AIMS there is no additional install of software on the end-point server for the connector to function (agentless).  There are 28 different connects currently offered OOBincluding AS/400, Linux, various Microsoft (SQL, Windows, ADAM), Novell, Oracle, PeopleSoft, SAP, Sybase and Sun.  On the Access Management side, AIMS offers several web agents for the following platforms, IBM iSeries, IBM AIX, Linux, HP-UX and Sun Solaris.

Functionality

There are 8 core functions within the AIMS suite, Account Creator, Account Terminator, Compliance Auditor, Identity Analyzer, Identity Enforcer, Password Bouncer, Password Station and HR Feeds. These are installed as part of the base install of AIMS. Interestingly enough, all of the functions are configured through GUI windows and no scripting is involved.  Another nice touch with the product is the workflow is automagically built based on your configuration unlike many other products where you have to build it through scripting. 

The Identity Enforcer is the primary function of the product, this is where you configure Delegation, Org Charts, Reports, Security, etc…. . The product itself does have some pretty cool killer apps such as “Connect with IPad’”.  The reporting is stronger than many other products we have used and somewhat easier to configure. and the HR Feeds can read from several different databases (which is a given), such as Oracle, DB2, SQL-Server and MYSQL.

The Hits:

1. Password Station enables you to eliminate password reset calls to your internal help desk by allowing users to securely perform reset action themselves.
2. Password Bouncer improves on your password policy by allowing users only complex passwords that are difficult to crack.
3. Account Terminator automatically deactivates and captures account data from ex-employees as well as accounts that have been dormant and are no longer in use.
4. Account Creator automates all aspects of user provisioning thereby achieving great cost savings in starting new employees.
5. Identity Enforcer integrates workflow process of self-service authorization management.
6. Logon Station permits Single Sign-On so users only need to logononce to have access to every resource for which they are authorized.

The Verdict:

The maintence and setup is where the savings are compared to other market products. A big plus is that there is virtually no coding involved for workflow as AIMS can and will handle this automatically based on your configuration settings.  And a killer diller process that sets Avatier apart from others is the ability to get live updates (the platform is the only commercial off-the-shelf Identity Management solution I know that offers an optional Live Update service for automating software updates and upgrades but your mileage may vary with the usage of that one).

Once you have gained the knowledge of where everything resides in the GUI under specific functions the product is fairly straight forward to set up and while AIMS offers a lot of the same functionality as most of the IDM products on the market, such as Workflow, Reporting, Creating/Deleting Users and Reconciliation of Users across multiple platforms, it also offers a built in Role Mining function.

All in all a pretty bang up product addition to the Identity & Access Management market place.

Agree, Disagree or have a product we should be tackling next? Sound off below or feel free to reach out to us at IDMWorks.

Tips & Tricks: CA SiteMinder User Directory Tuning

Monday, August 29th, 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***

Today I thought I add a few tips & tricks related to CA SiteMinder Directory Services Tuning, as usual, any questions or comments you might have can be added below.

Adding Additional Directory Connection Pools

A major tuning parameter of the Directory Services is enabling additional directory connection pools. For each Policy Server and smsuserdirectory object defined a ldap connection pool is created.  In addition, for Load Balancing, an additional pool is created for each load-balanced LDAP server object.

To enable the additional pools for the LDAP server object, you can define the same directory server host as a load-balanced server. The result is the connection pool for the same logical host can double or triple the number of connection pool entries for a single directory object.

Measuring Directory Performance

In past deployments it has been shown that doubling the connection pool increases performance.
It is recommended that a monitoring tool be used to evaluate the overal performance gain.


Enabling the SiteMinder profiling logs and specific LDAP component categories can accurately measure the policy servers directory performance.
The following log entry from an Identity Manager policy evaluation shows the time in milliseconds taken to execute a user attribute lookup from a role membership rule.

The log entries below uses a time stamp of hh.mm.ss.ms. The ms or milliseconds portion is only enabled when the above PreciseTime data field is used.

As you can see from the highlighted text in the log entries below, this lookup returned in 8 milliseconds.

[04/16/2008][11:25:34.192][IMS6LdapRules.cpp:539][7728][Enter function
CIMSDsLdapProvider::findManagedObjects][CIMSDsLdapProvider::findManagedObjects][][][][][][][][]
[04/16/2008][11:25:34.192][IMS6DsLdapProvider.cpp:6527][7728][Additional filter: (location=Charlotte)
.][CIMSDsLdapProvider::ConstructSearchFilter][][][][][][][][]
[04/16/2008][11:25:34.192][IMS6DsLdapProvider.cpp:6564][7728][Constructed filter:
(&(objectclass=top)(objectclass=person)(objectclass=organizationalperson)(objectclass=inetorgperson)(location
=Charlotte)) .][CIMSDsLdapProvider::ConstructSearchFilter][][][][][][][][]
[04/16/2008][11:25:34.192][IMS6DsLdapProvider.cpp:2893][7728][Search Root:
uid=wcotton,ou=people,ou=Dealer,ou=NeteAuto,dc=ca,dc=com, Search Filter:
(&(objectclass=top)(objectclass=person)(objectclass=organizationalperson)(objectclass=inetorgperson)(location
=Charlotte)), LDAP scope: 0, IMS scope 3][CIMSDsLdapProvider::FindIMSObjects][][][][][][][][]
[04/16/2008][11:25:34.200][SmDsLdapProvider.cpp:2039][7728][Ldap Search callout
succeeds.][CSmDsLdapProvider::Search][(Search) Base:
'uid=wcotton,ou=people,ou=Dealer,ou=NeteAuto,dc=ca,dc=com', Filter:
'(&(objectclass=top)(objectclass=person)(objectclass=organizationalperson)(objectclass=inetorgperson)(locatio
n=Charlotte))'. Status: 1 entries][][][][][][][]
[04/16/2008][11:25:34.200][IMS6DsLdapProvider.cpp:2917][7728][Number of DNs returned
1][CIMSDsLdapProvider::FindIMSObjects][][][][][][][][]
[04/16/2008][11:25:34.200][IMS6LdapRules.cpp:578][7728][Leave function
CIMSDsLdapProvider::findManagedObjects][CIMSDsLdapProvider::findManagedObjects][][][][][][][][0]

As always, questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

Oauth vs. Xauth – When to pick the “O” vs. the “X”

Tuesday, May 31st, 2011

Oauth vs.Xauth (Open Authorization vs. Extended Authorization), there have been wars fought over less.  while  not getting into the philosophies that separate the two sides let’s start by looking at them as two separate tools.

The analogy is as follows: I can appreciate a good flat head screw driver and I believe there are jobs that require a Phillips screw driver. And while many Phillips screws can be worked with a flat head screw driver a Phillips screw driver won’t work on a flat head screw.

Such is the case with Oauth and Xauth.  Both will accomplish sign on using an Oauth token, however Xauth is more a form of Oauth light, only really appropriate in a small percentage of applications.  But be aware you still need to understand the Oauth authentication process, even when using Xauth.

Xauth is typically used for mobile and desktop applications that don’t use a browser directly.  Oauth is used for browser based authentication.  But this may be too much of a simplification.  I prefer that Xauth is used when Oauth can’t be used.  And when using Xauth you must also figure out how to dispose of the name/password that was used to retrieve the token.

Questions, comments or concerns are always welcome.  Feel free to reach out to us at IDMWorks.

Attribute Based Access Control (ABAC) – The Next Big Piece of the Puzzle

Tuesday, May 24th, 2011

Identity Management is a very important part of today’s responsive IT environment.  For about the last dozen years or so we have all been working diligently to connect each of our disparate systems and provision everything that we could get our connectors attached to.  Identity Management continues to be a huge issue for many organizations.  How does a large multi-national company maintain the tens of thousands of identities that access their systems each day.  Or how does a medium sized company with a lean staffed IT department maintain their internal identities and also manage the B2B relationships and systems accesses that come along with them?

But now that we’ve got identities provisioned and accesses granted to the key systems what do we do with all of that great information we’ve been gathering about the users?  We grant and/or deny access to services with it. As a result we moved into the realm of role based access control.  When a user had a change of role within an organization we reflected that in their digital identity.  From there we may provision a change to a downstream system or application that changes their access to an application or other data source.  This approach provided us a much more dynamic environment that reacted to the ever changing roles within an organization but it still had one big issue, the applications security needed to be tightly integrated to the system of record whether that be Active Directory, Oracle or some other authoritative system.  This approach is very costly and time consuming, especially in today’s dynamic IT environment.

Through Identity Management we effectively made Identity as a Service (IDaaS) to be consumed by the disparate systems in the enterprise.  Access management has accomplished the same thing for authentication.  But authorization has continued to be heavily the burden of the application itself.  This is where Attribute Based Access Control (ABAC) and the XACML standard become part of the complete security picture.  ABAC effectively takes the burden of authentication away from the application and provides it as a service within the organization to be consumed by any application or data source that needs protection.  XACML makes this idea a reality by providing a standard by which the different components can effectively speak the same language for authorization services.

An ABAC deployment has several advantages which include dynamic access to critical data based on an individuals attributes instead of a preset ACL or provisioned access.  Access is evaluated at the time of request and either granted or denied based on the requester’s attributes.  This has particular advantage in a federated environment where the owner of the system may not own the identity that is requesting the resource.  It is not the job of the authorization service to establish the identity, that is handled by the identity and authentication services.  It is simply the job of the authorization service to determine if the authenticated identity is granted access to the protected resource based on a policy that is interpreted at the time of the request.

There are a number of components that make up an ABAC solution.  These components include, but are not limited to, a Policy Decision Service (PDS) also known as a Policy Decision Point (PDP), a Policy Enforcement Point (PEP), and an Attribute Service (AS) also known as a Policy Information Point (PIP).  When implemented according to standards these components may be provided by a single vendor or chosen across multiple vendors based on best in class technology.  There are a number of vendors that provide these services including, but not limited to; Axiomatics, Bitkoo, Oracle, CA, Jericho Systems,Vordel, Cisco, Siemens, Epok, Layer 7, Quest, Pericore, NextLabs and IBM. Each of these vendors, and others, provide standards based (XACML) solutions that allow the application developers to concentrate on implementing the business logic of the application and allow the authorization to be handled externally.

While the level of integration with the application varies across the vendors along with the back end systems/data sources varies as well, it is clear that a large step has been taken with ABAC and XACML moving toward Authorization as a Service.  While there is still some work to be done (some of which is very clearly addressed in the XACML 3.0 specification) this is a solution that is ready for wide adoption.  I think it can be confidently stated that Attribute Based Access Control is truly the next big piece of the puzzle for many service hungry IT environments.

As always, questions, comments or concerns?  Feel free to reach out to us at IDMWorks.

Web Single Sign-on (SSO) using SAML 2.0 & Shibboleth

Sunday, March 13th, 2011

In the past decade we’ve literally seen an explosion of web based applications make their way into many big and small businesses.  No doubt, the payoff has been great.  With various business models, such as Amazon and Ebay, the Web Service concept was born allowing companies to consolidate several “stores”, aka Portals, and offer the consumer a one-stop-shopping experience.

The same opportunities made their way to large corporations.  Big companies with affiliates, such as 401K, Health Insurance, and Payroll providers are able to offer their employees access to portals built directly inside company’s intranet sites.

With these implementations new challenges have arrived.   For example, in order for an employee to see his or her payroll and file a medical claim, the employee would have to log onto 2 separate sites and provide a set of credentials to each before being able to get access to each portal.

So how do we solve this issue?  The concept is simple and certainly not new today.  But the adoption of the SSO technology had been pretty slow up until about 5 years ago when the adoption of the single sign-on soared.  The main reason for such rapid growth is technology maturity.

There are various single sign-on authentication technologies today.  Common examples of Enterprise Single Sign-on (ESSO) are Windows Integrated SSO allowing the user to access applications within the network.  Another example is a Server based SSO allowing systems such as a RACF Mainframe  to be used by a user authenticated utilizing Active Directory.

And there is a Web Single Sign-On enabling the user to access resources over the Internet using a single set of user credentials

For this blog entry we will focus on Web Single Sign-On technology managing authentication using web based protocols.

Let’s look at the typical Federated Single Sign-On scenario: Health Care and 401K providers are doing business with an Employer and have their sites available to employees within Company intranet site.  An employee of the company has to (1) log onto the company’s intranet site, (2) log onto the 401K site By adding SSO the user will be able to log on once and let the trusted partners ascertain that the logon was a success. In other words, if you authenticate your employee against your Directory, then I trust you and will allow him/her to enter my site without prompt for credentials.

There are several Single Sign On implementation methods developed and available today:

In future blogs we plan to cover each of the methods in details, but today we will explain the benefits of SAML-based authentication and Shibboleth metadata validation.

SAML is an XML-based framework. With proper formatting and following the guidelines and standards of the OASIS consortium, it allows businesses to make secure assertions and securely exchange identity information.

Information Exchange

On March 28, 2008, The Oasis Technical committee laid out well-defined standards for SAML 2.0.  Perhaps most important is the Metadata requirement.   Without properly formed Metadata the Identity Provider fails during parsing.  The required end point location must be properly defined for an Identity Provider to build a SAML response and to redirect the user to a proper destination.

An example of metadata (below) shows required elements for an Identity Provider to understand a SAML request:

<EntityDescriptor xmlns:saml=”urn:oasis:names:tc:SAML:2.0:assertion” xmlns:ds=”http://www.w3.org/2000/09/xmldsig#” entityID=”https://site.with.certificate.com”><SPSSODescriptor AuthnRequestsSigned=”false” WantAssertionsSigned=”true” protocolSupportEnumeration=”urn:oasis:names:tc:SAML:2.0:protocol”>

<KeyDescriptor use=”signing” xmlns:md=”urn:oasis:names:tc:SAML:2.0:metadata”>

<ds:KeyInfo xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”>

<ds:X509Data xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”>

<ds:X509Certificate xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”>cert info</ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

</KeyDescriptor>

<AssertionConsumerService isDefault=”true” index=”0″ Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Location=”https://home.customer.redirect.location.com” />

</SPSSODescriptor>

</EntityDescriptor>

Metadata Validation using Shibboleth

Shibboleth is an open source software package for web single sign-on.   The schema file used in validation is included as part of the package and installs to /usr/share/xml/opensaml/saml-schema-metadata-2.0.xsd by default.

  • XMLSEC Tool: validates the schema as well as well-formedness of the metadata document.

The following syntax is used to perform validation:

o    xmlsectool.sh –validateSchema –schemaDirectory /usr/share/xml/opensaml/ –inFile your-metadata.xml

  • XMLLINT:  This utility is included with RedHat and allows you to validate metadata against the predefined OASIS SAML  schema metadata XSD file.  To perform validations on RedHat execute following command:

o    xmllint –schema http://docs.oasis-open.org/security/saml/v2.0/saml-schema-metadata-2.0.xsd –noout example-metadata.xml

As usual if you have questions, comments or concerns feel free to reach out to us at IDMWorks.

Starting Tivoli Access Manager for e-business & Tivoli Directory Server

Wednesday, February 23rd, 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***

I’d like to present the  recommended order for starting the Tivoli Access Manager for e-Business (TAMeb) processes, including IBM Tivoli Directory Server (ITDS).

The TAMeb and ITDS components are often distributed across multiple machines. When your deployment spans more than one machine, switch to the appropriate machine to complete the instructions for starting each component.

1. Start the registry server that was used to configure TAMeb.

* When using ITDS as the registry server, verify that db2 is running and then start the Directory Server process (ibmslapd).

2. Start the policy server. Ensure that the registry server is running and can be accessed before starting the policy server (pdmgrd).

3. Verify that pdadmin can be used for administration commands. After the policy server has started, you can use pdadmin or any other TAMeb administration application.

4. Start any blades servers (for example, WebSEAL) or any local mode authorization applications.

*Local mode authorization applications need to receive the latest policy database from the policy server, but otherwise do not depend on the policy server. Any local mode authorization application (for example, WebSEAL) can start and run without direct dependence on the policy server, as long as the application has a local copy of policy database, and as long as the registry server is running. Remember, however, that the application requires the policy server to be running in order to complete administrative tasks such as managing junctions.

* To start WebSEAL, you can use the command:

pdweb start InstanceName

* When your deployment includes junctioned backend Web servers ensure that those servers are running.

5. Start the authorization server. All remote mode authorization applications require that the authorization server (pdacld) is running. Most of the TAMeb Java Authorization applications are remote mode application.

6. The authorization server has a local copy of the policy database. The authorization server does not rely on the policy server, with the exception that when the authorization server starts it must be able to obtain any updates to the policy database.

* WebSEAL and the authorization server can be started in any order. They are not dependent on each other.

7. When your deployment includes any remote mode authorization applications, start them now.

8. When your deployment includes a policy proxy server (pdmgrproxyd), start it now.

9. When your deployment includes the WPM administration console, or any TAMeb Java Application that runs under WebSphere, ensure that the the applications are running by stopping and restarting WebSphere.

* You can use the command pd_start startto start the following TAMeb servers:

  • Policy server
  • Policy proxy server
  • Authorization server
  • WebSEAL servers

* When the policy server (pdmgrd) is configured on a machine, the command pd_start start always starts the policy server process first and then starts the other configured processes in order. To determine the order, use the command:

pd_start status

Stopping the TAMeb and ITDS processes

In most cases, you can stop the TAMeb and ITDS processes in the reverse order in which they were started. For example:

1. Stop any admininstration applications, such as pdadmin.

2. Stop any authorization applications.

3. Stop the TAMeb servers such as the policy server, authorization server, policy proxy server, and WebSEAL server. You can use the command:
pd_start stop

4. When appropriate, stop the registry server.

Questions? Feel free to reach out to us at IDMWorks.

Identity Management & the Art of Removing Cloud Security Obstacles

Thursday, February 17th, 2011

First the fun, why Cloud?  Well, we seem to define this a lot here at IDMWorks.

The quick and dirty:

1. Pay As You Go Approach to IT
There is no upfront cost and this helps keep the cost down for the service consumers. Cloud computing is a pay-as-you-go approach, in which a low initial investment is required to get started, and additional investment is incurred as system usage increases.

2. Highly Available Infrastructure
Many cloud providers sell their service as highly available. This gives Cloud services the aura of a utility which is an always on and that can be leveraged anytime and from anywhere.

3.  Strong Time to Value Ratio
With Cloud computing organizations realize benefits more rapidly than with the traditional packaged software use model. In the traditional IT model, a large investment is made early in the project prior to system build out, and well before tangible business benefits are realized. This model has several risks associated with it since a large percentage of IT projects are cancelled due to poor ROI or user acceptance. Cloud provides IT a way to outsource non critical functions to an organization better equipped to run those services.

4. Flexible Computing Model
Cloud computing offers much more flexibility than traditional computing models. Your Employees can access information wherever they are rather than having to be restrained to their desktop.

5. It’s Simple
One of the advantages of cloud computing is that businesses of all sizes can instantly obtain the benefits of the enormous infrastructure without having to implement and administer it directly.

Enough of the pitch, now on to Identity Management in the Cloud

Cloud Identity Challenges:

1. User Lifecycle Management:
New Cloud applications bring new complications of management, more costs and administrative hassles. You may have invested hundreds of thousands or even millions in enterprise provisioning software only to find out that it does nothing to address your identities in the Cloud. There could be windows of time where your terminated contractors may not have been de-provisioned from critical applications.   As such, organizations will quickly find out they need a centralized infrastructure to manage user identity information effectively.  Further, explosive growth in the use of web applications increases the complexity and administrative overhead of which users should be entitled to access across applications. So it is critical in the cloud framework to be able to facilitate self-service registration whenever possible. This can lead to better agility, reduced help desk costs and higher convenience for end users.

2. Compliance:
As more services and applications are being provided by 3rd parties, organizations have new compliance issues to worry about. The more sensitive data we have via these 3rd party applications the more we need to be able to enforce the types of controls that allow us to be compliant.

3. Federated Authentication:
The ability to collaborate seamlessly with your partners, vendors, and customers. An organization may already have all of its internal user identities stored in Active Directory and its external users such as partners and vendors in an LDAP directory and the organization may want all of their users to leverage an external cloud application without replicating all of that identity information in a third party product. Many organizations also want the convenience of having their users sign on once to access not only internal applications but also SaaS applications in the cloud.

Cloud Identity Solutions:

1. User Lifecycle Management:
Identity Administration helps solve the user lifecycle management challenge and many other common issues such as self service registration and compliance reporting.  Automation of provisioning and de-provisioning of users and administering user identities for both on premise and cloud applications will bridge the security gap regardless of the size of the network.  The addition of Role Based Access Control (RBAC) allows for when a user changes a role they are automatically de-provisioned from systems no longer needed and added to new ones relevant to their new role.  Additionally, automated Identity Administration allows us to identify and remediate orphaned accounts (those accounts with long gone owners).

Throw in user self-service access requests and self-service password reset capabilities and the User Lifecycle Process can be fully automated across the Cloud.

Need this to be standards driven?  Let’s implement SPML connectors.

2.  Compliance:
Simply put, utilize Identity Management tools to log and report Who has access to What, When, Why, and How and fulfill those pesky regulatory requirements, such as Sarbanes-Oxley, 21 CFR Part 11, Gramm-Leach-Bliley, HIPAA, and HSPD-12.

3.  Federated Authentication:
Need to collaborate seamlessly and yet securely across complex heterogeneous environments?  Make sure your Single Sign-On solution can support SAML, Windows CardSpace, WS-Fed and/or OpenID.

In summation, contact IDMWorks and let us help you plan your Cloud based Identity & Access Management (IAM) security solutions around the core tenets:

1. Identity Management

a. Roles based User Provisioning

b. Self-Service Request &  Approval

c. Password Management

2. Access Management

a. Authentication & Fraud Prevention

b. Single Sign-On & Federation

c. Authorization & Entitlements

d. Web Services Security

e. Information Rights Management

3. Governance, Risk and Compliance (GRC)

a. Analytics

b. Fraud Prevention

c. Privacy Controls