I think I get the gist of it. My understanding of the provided plug-in (and associated Remedy forms for AREA config) is that Remedy would log-in/authenticate/bind to a LDAP as some type of user (say "RemedyUser") that is allowed to log into the LDAP.
>From there, Remedy would pass the users credentials to LDAP...something like "Hi Mr. LDAP. I am RemedyUser, already authorized to query your directories. I have this user, JoeUser, who needs to authenticate. Is his login and password correct?" At which point, LDAP would respond with a yay or nay. What I'm trying to do is something like: "Hi Mr. LDAP. I'm JoeUser with xxx password. Am I authorized?". At which point, a yay or nay would result. On a 'yay' result, Remedy would allow access. Does my dummied-down sample muddy the water any more? :) J.T. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Friday, September 21, 2007 10:34 AM To: arslist@ARSLIST.ORG Subject: Re: Sample java LDAP plugin 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/l dap/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: arslist@ARSLIST.ORG > 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" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
