Layer7 API Management

Hi Folks,

                We have a situation where there are multiple Identity Providers to be used by Oauth manager.  I looked into the documentation & it suggests to update the toolkit policy to add assertions to authenticate from other Identity Providers other than the CA internal IDP.

Adding multiple Identity Providers manually in the policy is not looking like a good idea since there are few IDs which are present in both the Identity Providers Also we would be trying to authenticate against all Identity Providers for all IDs which is lot of unnecessary calls.

Also can we add logic to go to a database at the same locationinstead of going to LDAP?

Thanks,

Abhishek

Hi Abhishek,

As I am aware, the process you mentioned is the only way to set this up. If you edit the 'OTK User Authentication' fragment to include branch logic (At least one assertion must evaluate to true) for each identity provider there is potential for the overhead you are trying to avoid.

I.e: If you have 7 identity providers and the user is not found until the 7th branch there were a lot of unnecessary calls to other IDP's.

I am not familiar with another way to accomplish what you need.

Also, Can you clarify what you meant in your last question, "Also can we add logic to go to a database at the same location instead of going to LDAP?"

Are you looking to query an external database with user accounts (mysql, Oracle, etc) rather than hitting LDAP directly?

Regards,

Joe

Hi dasjo02,

                  Thanks for your detailed response. Yes we are looking to use an external database as an authentication provider instead of LDAP.  If we add it to the OTK policy, the only way I can see is to put it in the last branch. But we do not want to compromise our performance capabilities.

I also observed, this is an issue only in case of folks using only CA Gateway capabilities.Mobile Gateway can handle multiple IDPs by default.

I can see no other way but to ask clients to send some kind of parameter in the request for us to identify the IDP. It would be great if Oauth toolkit provides a way to pass a predefined parameter to handle such scenarios by default instead of us tweaking  well tested toolkit policies.

I will be submitting this idea in the community.

Thanks,

Abhishek

Hello Abhishek!

Thanks for you explanation. Am I right that you would like OTK User Authentication to accept an additional parameter that enables the policy to use a certain IDP? That is a good idea which we already have discussed here in the OTK team.

But please be aware that you would still have to modify that policy to handle a specific branch (IDP). OTK cannot know which IDP you may want to use and how you want to identify it.

As to your question regarding the database IDP, that should have its own branch within that policy.

CA Mobile API Gateway (MAG) leverages the same authentication methods as OTK. The only addition is that MAG supports social login. If an additional social login platform should be supported policy work is required.

Something we are looking into is that OTK User Authentication could include an empty encapsulated assertion especially made for customers. It would be installed but would not do anything by default. You as a customer could then implement the inside of it. For example, supporting a database backed IDP. Using this approach would allow you to add whatever you want but without touching the OTK policies itself.

Please let me know if you have any questions or other suggestions.

I have used "scope" value to accomplish this. scope="ldapconnectionname" defined in Auth configuration and leveraged this to authenticate against a particular IDP based on scope.

I am not sure if OAuth spec allows "scope" for this purpose, but it did made my life easier with little changes to the outofthebox policies.

Regards,

Ganesh Reddy

Hi Ganesh!

The OAuth 2.0 spec does not specify values for SCOPE. But they are more or less permissions that resource owners have to grant or deny. Usually clients request permissions to access some sort of resource. Therefore SCOPE may be a good workaround but not ideal in this case.

Nevertheless thanks for sharing this info and I will post an update when we have a good understanding on how we will support this use case.