I think there is some terminology confusion. In the universe of ldap, the bind operation must be issued to check the authentication credentials provided. The pre-compiled plug-in may authenticate as some user and have a persistent session (been too long since I used it, but I see a place where username/password is stored to connect to the ldap server).
There is a skeleton area plug-in for ldap included in the api for 7.0.1: http://arswiki.org/projects/arapi/browser/releases/linux701p3/src/area/ldap/arealdap.c This may meet your needs, you just have to compile it. It does not support ssl, but it also does not store or create persistent sessions to the ldap server. It looks to simply bind using the credentials provided by the user at the time they attempt to login, then passes a token back to the arserver based on the results of the bind operation. As I stated before, in ldap terms, 'bind' is synonymous with 'authenticate'. To check a set of credentials, a bind operation generates response that must be available to make a decision. >From http://www.ietf.org/rfc/rfc2829.txt 5.1. Anonymous authentication procedure An LDAP client which has not successfully completed a bind operation on a connection is anonymously authenticated. ... 6.1. Digest authentication An LDAP client MAY determine whether the server supports this mechanism by performing a search request on the root DSE, requesting the supportedSASLMechanisms attribute, and checking whether the string "DIGEST-MD5" is present as a value of this attribute. In the first stage of authentication, when the client is performing an "initial authentication" as defined in section 2.1 of [4], the client sends a bind request in which the version number is 3, the authentication choice is sasl, the sasl mechanism name is "DIGEST- MD5", and the credentials are absent. The client then waits for a response from the server to this request. The server will respond with a bind response in which the resultCode is saslBindInProgress, and the serverSaslCreds field is present. The contents of this field is a string defined by "digest-challenge" in section 2.1.1 of [4]. The server SHOULD include a realm indication and MUST indicate support for UTF-8. The client will send a bind request with a distinct message id, in which the version number is 3, the authentication choice is sasl, the sasl mechanism name is "DIGEST-MD5", and the credentials contain the string defined by "digest-response" in section 2.1.2 of [4]. The serv-type is "ldap". The server will respond with a bind response in which the resultCode is either success, or an error indication. If the authentication is successful and the server does not support subsequent authentication, then the credentials field is absent. If the authentication is successful and the server supports subsequent authentication, then the credentials field contains the string defined by "response-auth" in section 2.1.3 of [4]. Support for subsequent authentication is OPTIONAL in clients and servers. ... Axton Grams On 9/21/07, Davies, J.T. <[EMAIL PROTECTED]> wrote: > Hi Axton, > > Basically, we're going to take what the user enters in for > login/password and use that in an attempt to log in to the remote > LDAP...not using a bound connection. The other application uses that > method, and the LDAP admins says its ok. > > J.T. > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Axton > Sent: Friday, September 21, 2007 9:23 AM > To: [email protected] > Subject: Re: Sample java LDAP plugin > > Prior to 7.1, AREA plug-ins must be written in C. With 7.1, there is a > new java based plug-in server. > > The ldap bind is synonymous with a login attempt. So when the area > plug-in binds to the ldap server as the authenticating user, the plug-in > is acting based on the response code the ldap server returns from the > bind operation. > > How do your ldap admin's want you to authenticate against the ldap > server without performing a bind operation? > > Axton Grams > > On 9/21/07, Davies, J.T. <[EMAIL PROTECTED]> wrote: > > ** > > > > Good Friday morning...finally. > > > > I'm new to the Java development world, and yet I've been tasked with > > something fairly intermediate/advanced. > > > > Here's my situation: I need to have Remedy communicate to a LDAP for > > authentication (via AREA). I can't use the stuff provided by > > BMC/Remedy because it binds to the LDAP...and due to restrictive > > security policies...it's not going to be done unless absolutely > necessary. > > > > So, here's my plan. (I'm mirroring this off of another application we > > > have [non-Remedy] that uses this LDAP for authentication). > > > > AREA plug-in. Remedy passes authentication information to this > plug-in. > > The plug-in takes this information and attempts to authenticate to the > > > target LDAP. If successful, passes message back to Remedy that > > they're OK to log in, otherwise not. > > > > It sort-of reminds me of a brute-force type of login for hacking...but > > > it's not. > > > > Does anyone have any sample code of a Java plug-in?? (Maybe not > > necessarily for AREA authentication...but just some small app that > > demonstrates the classes and methods that the plug-in server use [and > > more specifically, the structure and syntax]). > > > > I've got the Integrating manual, and it's got a lot of samples, but > > they're mostly in C... The samples they do provide for Java aren't > > used with AREA or the plug-in server. > > > > > > Thanks! > > J.T. Davies > > New Edge Networks, Inc. > > An EarthLink Company __20060125_______________________This > > posting was submitted with HTML in it___ > > ________________________________________________________________________ > _______ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where > the Answers Are" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the > Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
