Apigee Edge 4.17.05 - policy/token/active directory/soap

Not applicable

Hi all , can you please confirm that Apigee Edge 4.17.05 supports the following list of features?

1) Policy integration with Active Directory. We neeed to retrieve user attributes.

2) Policy generate access token bearer oauth2 for a specific user and scope (user token).

3) Policy to enrich http header parameters (in case of user token usage) forwarding the api request to the final back end. The attributes to be enriched are the ones retrieved from Active Directory (previous point 1).

4) Interface Agreement of the API to use for publishing API Proxy with soap endpoint.

5) possibility to add custom attributes on organization (in order to retrieve them when an API is invoked by using token application)

Thank you

Cosimo

Solved Solved
0 9 206
1 ACCEPTED SOLUTION

Yes, all of those things are supported.

  1. The LDAP policy can be used to connect to ActiveDirectory for authenticating inbound requests.
  2. The OAuthV2 policy with Operation:GenerateAccessToken creates tokens, including user tokens. You can combine the LDAP policy with GenerateAccessToken to verify the user externally before generating the user token. You can also attach AD user attributes (like group affiliation) to the token that gets issued.
  3. Use the AssignMessage policy can inject headers to the southbound request. These headers can be derived from the attributes attached to the token. The API Proxy will first call OAuthV2 with Operation:VerifyAccessToken , which checks the token and retrieves the user attributes. Then you can use AssignMessage to set headers with those attribute values.
  4. As for "interface agreement" I don't know precisely what you mean by that, but Apigee Edge proxies can accept SOAP inbound, and can send SOAP outbound. Accepting SOAP inbound does not require SOAP outbound, and vice versa. This means you can build REST-to-SOAP proxies, eposing REST outbound and invoking an existing SOAP service. You can also build SOAP-to-REST proxies, which accept SOAP inbound and invoke a REST service. This is less common but not uncommon. The way you would do either of these things is not with a single policy but by constructing a proxy. There's a WSDL import Wizard to assist, or you can build a proxy "manually", pretty quickly.
  5. Apigee Edge includes a Key-Value Map to store attributes. The KVM can be scoped to the organization, to the environment, or even to the API Proxy. You can use the Edge Admin UI or API to set values into the KVM. And use the KeyValueMapOperations policy to retrieve those values from within an API Proxy.

View solution in original post

9 REPLIES 9

Yes, all of those things are supported.

  1. The LDAP policy can be used to connect to ActiveDirectory for authenticating inbound requests.
  2. The OAuthV2 policy with Operation:GenerateAccessToken creates tokens, including user tokens. You can combine the LDAP policy with GenerateAccessToken to verify the user externally before generating the user token. You can also attach AD user attributes (like group affiliation) to the token that gets issued.
  3. Use the AssignMessage policy can inject headers to the southbound request. These headers can be derived from the attributes attached to the token. The API Proxy will first call OAuthV2 with Operation:VerifyAccessToken , which checks the token and retrieves the user attributes. Then you can use AssignMessage to set headers with those attribute values.
  4. As for "interface agreement" I don't know precisely what you mean by that, but Apigee Edge proxies can accept SOAP inbound, and can send SOAP outbound. Accepting SOAP inbound does not require SOAP outbound, and vice versa. This means you can build REST-to-SOAP proxies, eposing REST outbound and invoking an existing SOAP service. You can also build SOAP-to-REST proxies, which accept SOAP inbound and invoke a REST service. This is less common but not uncommon. The way you would do either of these things is not with a single policy but by constructing a proxy. There's a WSDL import Wizard to assist, or you can build a proxy "manually", pretty quickly.
  5. Apigee Edge includes a Key-Value Map to store attributes. The KVM can be scoped to the organization, to the environment, or even to the API Proxy. You can use the Edge Admin UI or API to set values into the KVM. And use the KeyValueMapOperations policy to retrieve those values from within an API Proxy.

Please @Dinofor each point can you add a link to offcial documentation that explain how meet it?

Thank you

Cosimo

Done. You're welcome!

Hi @Dino thank you a lot.

Just one question on point 2. We don't need to verify that the user exists in LDAP and we don't need to link user attributes to the access token. We need to store on database the user name and the scope. We verify the saml signature, the saml issuer, the expiration date of the saml. After this check we need to generate access token and associate it to the subject of the saml assertion (is an user name). When i use this token in order to invoke an API we need to retrieve the username and retrieve from LDAP the attributes of this user.

Furthermore, is it possible to use mysql as database instead of cassandra?

Thank you

Cosimo

What you describe should work. But there may be a better way. I suppose that you will not want to call LDAP each time the token is presented. It may be easier to call to LDAP when the token is generated; you can then attach attributes to the token; these attributes can be values that you retrieved from LDAP.

It is not possible to use MySQL to store the tokens. Apigee Edge OPDK uses Cassandra, for now. There is no possibility to swap this out. We may make a change in the product, in the future, to allow a different store, but we have no plans to do so at this time.

Hi @Dino we need to implement gran type saml.

In the answer to point 2) you say "OAuthV2 policy with Operation:GenerateAccessToken creates tokens, including user tokens." If you mean to use gran type = passoword it does not work for our scenario because we have to generate the access token just starting from saml assertion or jwt. Just the username of the user is available and the password not.

We need saml and jwt gran type to exchange a signed saml assertion or signed jwt for an user access token. How can be implemented those gran types in Apigee.

Thanks

Cosimo

If you use the OAuthV2 policy with Operation:GenerateAccessToken, with grant_type=password, you should know that Apigee Edge itself does not validate the username and password. As a proxy designer, you are responsible for configuring the logic to verify the user creds before invoking the OAuthV2 policy with Operation:GenerateAccessToken and grant_type=password . I cannot recall now whether the policy with password grant_type requires an actual password. But if the policy does require a password, it will be checking for presence only; it will not be verifying the password. Therefore in the event the policy requires the presence of a password, you can set any dummy value to satisfy the policy's internal validations.

Also, I think @Srinandan Sridhar has built a proxy that exhibits RFC7522 SAML grant type. It may even be posted here on community.apigee.com. Nandan?

Former Community Member
Not applicable

Not applicable

Hi @Dino are all these features available also in apigee 4.15.01?