1 / 3

SCIM versus LDAP !

The Gluu Server is already open to the Internet on 443. But the ip address of all LDAP clients would need to be added as an exception to the Gluu Server host firewall. Ideally, the customer would want to specify an AWS security group. It sounds trivial, but given the other considerations, it helped tilt the scale for me towards SCIM.

gluu
Download Presentation

SCIM versus LDAP !

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SCIM versus LDAP! When it comes to pushing users to the Gluu Server, customers can use either the LDAP and sso service interface, or the SCIM interface. Which one should I advise them to use? Ok, I admit it… I love LDAP. I and about a thousand other weirdos scattered across the globe. What more do programmers want? UnboundID has written a fantastic Java client SDK. It makes it really easy to load balance connections to backend servers. There are many resources on the web on how to use LDAP. However, despite my love of LDAP, I am now firmly in the SCIM wagon. Here are a few quick reasons why: Stateless Connections If you make a mistake while using an LDAP API, it opens the possibility you will have an LDAP connection leak, consume all the available connections and crash the server.

  2. Hides complexity of LDAP – The Gluu LDAP namespace assigns a unique identifier to each organization that is not exactly programmer friendly. Also, when adding a person the developer needs to know the required and optional attributes for a given LDAP object class. Not really a blocker, but explaining this extra stuff takes time, especially to programmers who are not LDAP geeks. Hard to manage LDAP ACI’s – Applications that need to write to the LDAP server would need credentials–an LDAP DN (distinguished name) and password (or register a certificate). Then this DN would need to be given access to perform the necessary operations. How to do this differs based on the backend LDAP Server (i.e. between OpenLDAP and OpenDJ). Hard to Manage Firewall Rules – The Gluu Server is already open to the Internet on 443. But the ip address of all LDAP clients would need to be added as an exception to the Gluu Server host firewall. Ideally, the customer would want to specify an AWS security group. It sounds trivial, but given the other considerations, it helped tilt the scale for me towards SCIM.

  3. One complication that contributed to my previous hesitation to recommend SCIM over LDAP has been that the SCIM standard does not say how to protect the APIs. The SCIM interface is very powerful–the ability to change passwords and add users = they keys to the kingdom Gluu’s approach is to enterprise single sign on it as we secure all API’s–using UMA. At this point, I don’t see any other viable open standard to secure APIs, so it seems like it’s the right approach. The net effect of these considerations has put me firmly on the side of SCIM. We still use LDAP in the Gluu Server for persistence (we love the replication and performance!). But as an interface for provisioning (aka IDM) we’re going to start pushing SCIM 1.1 from now on. LDAP is now deprecated. Article resource:-http://gluu.webs.com/apps/blog/show/42647606-scim-versus-ldap-

More Related