Apigee Edge LDAP Integration

rmishra
Participant V

Hello,

I am attempting to integrate Apigee with my corporate LDAP

Apigee Version: 4.17.01

We are using Indirect Binding, here are two properties

conf_security_externalized.authentication.user.store.user.attribute=sAMAccountName
conf_security_externalized.authentication.user.store.user.email.attribute=mail

In my LDAP, sAMAccountName is rmishra, while the mail attribute is rmishra@abc.com

In Apigee Edge, rmishra@abc.com is set up as an organization administrator

When i use the above configuration to login , i get an internal server error from edge-ui. The edge ui log shows

[debug] application - GET http://MS_IP/v1/users/rmishra/userroles
[error] application - Error response from Gateway:
Action: GET
URL: http://MS_IP/v1/users/rmishra/userroles
Headers:
  Accept: [application/xml]
  X-Apigee-Trace-Id: [bf25b3cf-3416-4262-97a7-5fe67decf005]
Response Status Code: 401
Response Body:
  (empty)
Headers:
  WWW-Authenticate: [Basic realm="users/rmishra/userroles"]
  Date: [Wed, 19 Jul 2017 18:03:14 GMT]
  Content-Length: [0]
 
[error] p.c.s.n.PlayDefaultUpstreamHandler - Cannot invoke the action
utils.GatewayErrorResponseException: null
        at utils.WsHelper.logAndBuildExceptionForGatewayErrorResponse(WsHelper.java:113) ~[enterpriseui.enterpriseui-4.17.01.04-4753fe9-20170531-002003-sans-externalized.jar:na]


I believe that in the above failure, authentication has been successful but authorization fails because my sAMAccountName instead of my email is being used to list my roles.

The above error goes away and i can log in when i switch the following attribute to "mail"

conf_security_externalized.authentication.user.store.user.attribute=mail 

It almost seems like my conf_security_externalized.authentication.user.store.user.attribute is being ignored for fetching roles.

Our goal is to enable Apigee Edge Logins with userId instead of email but it doesn't seem to work.

Any pointers will be appreciated

Solved Solved
0 6 1,154
1 ACCEPTED SOLUTION

rmishra
Participant V

@Floyd Jones I understand the fact that Apigee uses email for authorization using its internal OpenLDAP. That is not where the problem is.

Right now the behavior i am seeing is that, if i use "sAMAccountName" as my authentication attribute, the management server is using the same attribute(instead of using the mail attribute) for authorization.

When i use "mail" as my authentication attribute, everything just works fine.

I hope i am clearly explaining that there seems to be a bug where if the authentication attribute is anything but "mail", authorization does not work.

A few days after raising the question here we opened a ticket with Apigee support. They informed us that this is a known defect. We are waiting on more details.

View solution in original post

6 REPLIES 6

Hi @rmishra -

I believe that's working as expected. As described in the About authorization section of the "External Authentication" topic, Edge keys authorization off of email. Even though your LDAP handles authentication, Edge still handles the authorization layer in its own OpenLDAP, and it does it through email rather than username.

rmishra
Participant V

@Floyd Jones I understand the fact that Apigee uses email for authorization using its internal OpenLDAP. That is not where the problem is.

Right now the behavior i am seeing is that, if i use "sAMAccountName" as my authentication attribute, the management server is using the same attribute(instead of using the mail attribute) for authorization.

When i use "mail" as my authentication attribute, everything just works fine.

I hope i am clearly explaining that there seems to be a bug where if the authentication attribute is anything but "mail", authorization does not work.

A few days after raising the question here we opened a ticket with Apigee support. They informed us that this is a known defect. We are waiting on more details.

Gotcha. Thanks, @rmishra . Thanks for the clarification.

Has this bug been fixed?

Having same issue with version 4.18.05.00 - this post was written 2 years ago, is this possibly still a known bug - looking through release notes since 4.17.01 does NOT indicate that this has been fixed?

Can you ask this as a new question please?