open source identity management

Red Hat

Originally uploaded by Jim Yang Photos

Identyx is now Red Hat. http://www.press.redhat.com/2008/06/19/introducing-red-hat-enterprise-ipa-10/

UPDATE: Session ID: S297199, Title: Getting Started with OpenDS, Monday, May 05, 11:00 - 11:55, Moscone North - Hall E 133

Penrose 2.0 ships OpenDS, MINA, FedoraDS, and ApacheDS as Penrose’s LDAP Service Providers (SP). OpenDS SP is now enabled by default in Penrose 2.0. We have put together a presentation below to describe how we integrate OpenDS into Penrose. We will be co-presenting with Sun at JavaOne/CommunityOne 2008 next May. Here is a portion of our presentation.

Penrose 2.0 introduces a new concept called Directory Application Archive (DAR). It mimics tomcat’s WAR/EAR files. We have a new directory structure and separate class loader for each partition. DAR files (files with a .dar extension) are intended to contain complete directory applications. In this context, an directory application is defined as a collection of drivers, custom modules, libraries, binaries, mapping, partitions and other supporting files such as images or ldif files. We included at least a dozen of these applications under /samples directory.

Samples of Directory Application

Account Lockout DAR directory layout

To start exploring Penrose 2.0, check out our documentation. Let me know what you think.

NIS vs LDAP Gateway

NIS Gateway is a software which uses LDAP as its information source while permitting  existing NIS clients to transparently use LDAP to resolve user, group and host information.

LDAP Gateway does the opposite. It translates and/or caches NIS entries and provides LDAP clients to transparently use NIS information.

Penrose can be configured as an LDAP Gateway to NIS servers, perhaps the only implementation that is available on the market - someone correct me if I am wrong. The NIS translation can be done in a real-time or through a persistence/caching layer, such as a Fedora Directory Server. In cached mode, Penrose is acting as a synchronization agent.  The primary data is still being mastered in NIS server so the administration/changes of the data still need to be done via NIS.

Avoiding “Bigbang” Migration from NIS to LDAP

You are probably asking. NIS is deprecated and no longer supported by Sun, so why are we still keeping NIS ? if the data still resides in NIS, what is the point of all of this then ?

There are still quite a few organizations out there that still use NIS as their primary authentication and identity stores. Most of them have hundreds, thousands or sometimes tens of thousands machines which still rely on multiple NIS servers. Migrating all of these NIS clients into LDAP clients can’t be done overnight  (”bigbang” migration).

Virtual Directory as an LDAP gateway is designed to help the system adminstrator to avoid this “bigbang” migration.

One needs to understand the challenges of migrating to an LDAP infrastructure.

• “If It’s Not Broken, Don’t Fix it” attitude. The reality is NIS does work well. We know a very large enterprise company who can’t completely switch to LDAP because their operational team doesn’t know how to scale their LDAP infrastructure to handle thousands of LDAP clients. So they are still sticking with NIS despite the fact that they might not pass an internal security audit.

• LDAP is hard. The concept of LDAP is not as easily grokked as database technology. Furthermore, this type of migration is considered a high-risk/mission critical project. Somebody will be fired if something goes wrong that cause their operations to halt. System Administrator has to be familiar with LDAP technology inside out to perform this type of large scale migration.

You might ask why can’t you just dump NIS entries,  import it into a directory server and stick a NIS gateway in front of the directory server ? Well, there are two problems that we see with this approach.

1. Before you cut-over to LDAP, NIS server is still the primary and authoritative identity. If there is an imperfection with your NIS entries such as conflicted UID/GID, namespace collision, etc., you will be forced to clean the NIS entries before you can export it to a directory server. The clean-up processes are the most manual and challenging efforts. If you have multiple NIS servers/domains, you’ll be forced to analyze all of the NIS entries across all of NIS servers/domains. By the time you are done with the analysis, there is a good chance someone may have changed the NIS entries and reintroduced yet another conflict. It is like trying to shoot a moving target.
2. The communication between NIS client and NIS Server is not secure. Thus, sticking a NIS Gateway in front of LDAP server won’t fix this issue. The goal of moving to LDAP is not having the clients to communicate any information to the servers without a proper authorization and  secure channel (LDAP SSL/TLS is more secure than YP’s clear text)

With the imminent release of Penrose 2.0, we will be providing tools and processes that can help you move out of NIS to LDAP in a gradual fashion. So stay tuned!

To be continued…

Penrose can be use to provide an account lockout to block password guessing attack. Most directory servers aren’t equipped with this type of functionality. You will need to download our Penrose 2.0 nightly build to do this. Checkout the detailed configuration after the jump.

Safehaus is pleased to announce the immediate availability of Velo 1.0. Velo is an open source provisioning server with workflow, auditing and access management feature.

New and Noteworthy Features:

• SPML V2 compliance. ^new!
• Role Based Access Control (RBAC)
• Consolidated Employee Identity Attributes repository
• Accounts Attribute Synchronization
• User and Access Reconciliations
• Integrated work-flow engine for complex business processes
• Self Service interfaces
• Support many resources
• Support Complete Account Operations
• Specific typed actions can be added easily
• Centralized Password Policy and Password Synchronization.
• Auditing & Compliance.
• Powerful scripting support for complex processes via Groovy expressions
• Remote services access via Web-Services.
• Extensible via Events.
• Advanced Report Designer & Web-based Reporting Manager.
• Pluggable Authentication Handlers.
• Jboss and Glassfish Support

One of our customer is a large server hosting company. They currently maintain a large customer e-mails in Microsoft SQL 2005. They need to configure their SMTP/anti-spam software to authenticate/look-up against those customer information. They had been running a scheduled batch to dump their SQL database and re-import the entries into a directory. We suggested a better and more elegant approach. Using Penrose real-time translation, we map their SQL entries into an LDAP entries “on-the-fly”. Their SMTP/Anti-spam application is then configured to talk to Penrose via a standard LDAP protocol.  A detailed configuration, such as creating LDAP connector and creating user group in Mail Marshall, after the jump.

UPDATE: A complete documentation on how to “Aggregate Multiple Proxies” is now available including sample configuration.

The Good

Starting from version 8.1, PeopleSoft user’s credentials be validated against the directory; hence leveraging pre-existing authentication data in an LDAP directory service and achieve Single-Sign-On across multiple PeopleSoft applications. Furthermore, user data that is typically used in a LDAP directory (such as name, phone number, and email address) can be updated instantaneously or on batch interval when information changes in PeopleSoft database.

The Bad

However, PeopleSoft delivered LDAP Authentication interface can only authenticate against one Directory tree. PeopleSoft do support multiple LDAP authentication but only for fail-over and redundancy purpose. Each replica server must contains identical tree as the master LDAP server.

The Ugly

Under typical enterprise environment, where there are more than one directory trees (multiple AD implementations) exist, integration of PeopleSoft and multiple LDAP is only possible with customization to application sign-on process in PeopleCode. However, such customization is beyond normal support provided by PeopleSoft Global Support Center.

The Solution

Use Penrose to tie all the AD servers into one directory tree by Merging, Proxying and PTA-ing the AD servers.

Devils in the Detail

There are various ways for an application to authenticate against an LDAP server. Here is
a common method:

1. User enters username and password into the application.
2. The application will perform a search operation against the LDAP server to find the full DN of the LDAP entry representing the user. The application will supply a search filter, for instance: (sAMAccountName=)
3. For each DN returned, the application will attempt a bind operation against the LDAP server using the DN and the supplied password.
4. Upon a successful bind, the application will perform another search operation based on the DN to retrieve certain attributes (e.g. cn, mail, memberOf) that are needed by the application.

The problem is that many applications assume that all of the users will be located in a single LDAP server. In many cases, the users are spread out in different domains and different Active Directory servers. Penrose solves the problem by mapping the users into a single “virtual” tree. From the application’s point of view, all user are now located in a single LDAP server. When the application performs an LDAP operation on Penrose, Penrose will forward the request to the appropriate LDAP/AD server, and then forward the results back to the client.

Penrose 1.2.1 is out. This minor release fix a serious bug on Penrose Studio when dealing with Active Directory RootDSE and Schema. You can download it here: http://penrose.safehaus.org/penrose12/penrose-1X2-release.html

We, also, added a documentation on our 3-clicks wizard for creating an LDAP/AD Proxy using Penrose Studio.

With the latest release of Penrose 1.2, we completed our integration with the latest release of OpenDS (0.9). Penrose 1.2 bundled OpenDS; however, OpenDS is not enabled by default.

Here is a very simple instruction on how to enable OpenDS in Penrose.