How Apigee cloud setup works with on-premises exposed services behind CAS?

[#1]

I'm working on making enterprise API available to external customers. Apigee provides powerful features for selling API as a product and api monetization.

Use Case: We have our own on-premises CAS with LDAP implementation for SSO (single Sign-on) support among multiple apps. We have been planning to use API as a backend when making proxies in Apigee. for example 1- Create API proxy for each available backend service 2- Make API products using on fly using API proxies

Problem statement: what would be the API route when customers consume proxy layer available on Apigee cloud? for example 1- Apigee authenticate and authorize customers/developers on cloud when they access proxy layer 2- later proxy payer access the back-end service with consumer key 3- Backend service authenticate through on-premises CAS server using consumer key (assume account exist in LDAP as CAS working with LDAP) and initiate the session 4- Token is generated by CAS.... how customer or app developer use that token for next call? keep in mind.. next call is another proxy that is setup on apigee (and in turn it uses any available backend service)

i assume, proxy call on agigee cloud looks as follow ...apigee.example.org/customer/.... while backend service call that talks to on-premises CAS looks as follows ...example.org/customer....

Thanks!

[Former Community Member]

Hi @Kashif Kazi Apigee provides several options to deal with Identity & Authentication. You can leverage Apigee's API BaaS as an identity store where users and credentials are stored. You can build an API proxy within Apigee Edge that can delegate authentication to the API BaaS. In a similar way its very common to delegate authentication & token generation to specific Identity Management Systems & Authentication Services such as CAS.

Also its very typical to leverage OAuth policies within Apigee to secure access to the APIs. In the use case you describe you can let Apigee handle the OAuth token life-cycle management & delegate authentication to for eg: CAS. Apigee can communicate securely with CAS & also persist the token generated by CAS (using caching policies) to be used for future calls.

So a sample flow could look like this:

1. Client invokes an OAuth proxy endpoint on Apigee passing in the consumer key, consumer secret, user id & password (all of this can happen over https in a secure way)
2. OAuth proxy can implement the password grant flow and can delegate the authentication to CAS
3. CAS authenticates the user, initiates a session & generates a token that is sent back to Apigee. Apigee can persist that token in a cache and the OAuth proxy returns a OAuth access token (The CAS token can be stored as an attribute of the generated OAuth access token).
4. The client finally calls the protected API proxy passing in the OAuth access token.
5. Apigee validates the OAuth access token & if the token is valid, it loads the persisted CAS token and sends it to the backend service.

Hope this helps. Let me know if you think this will work in your use case.

[#3]

Thank you @Prithpal Bhogill for a detailed answer. Couple more things on the flow

1- When developer joins the development portal they create account with id/pwd and get consumer key, consumer secret

2- How i can get those credentials id/pwd(specifically) to make same credentials work with my CAS (with LDAP store)? OR what if my CAS has different credentials for the same account?

3- Once account is setup in my CAS, I authorize the developer on my development portal to create apps etc.

4- From a threat/security perspective, how to prevent direct discovery of backend services and CAS? developer must only connect through apigee.

5- I must be missing something but is it possible for a developer to get access to CAS token attribute of the OAuth access token? if they get this, they may use all available proxies hosted in my network. I plan to use Apigee product monitization feature to restrict access to developers based on their package.

6- access tokens usually short lived. OAuth and CAS token adds 2 layers of authentication. Could it cause some performance impact as well?

Thanks,

Kashif

[sudheendras]

A small correction - the consumer key and secret combination is generated only when a Developer registers his App with Apigee. It does not happen during the Developer registration as indicated by you in in Step 1.

[#5]

Thanks @sudheendra1 for a correction. Can I please also get update on remaining concerns.

Kashif

[sudheendras]

Sure.. As @Prithpal Bhogill indicated, you can embed the CAS token in the access token (OAuth) generated at Apigee.

When the app tries to request for a token, it presents Consumer Key & Secret and other credentials (username, password may be). The Consumer Key and Secret gets validated by Apigee and Username/password at CAS. So your CAS continues to authenticate the user. After a successful authentication, CAS generates an token. This token is wrapped with Apigee's token before giving it back to the app. Hence if the app tries to call the backend directly with the token generated at Apigee, it fails. This gives you an additional protective layer of security.

Does it impact your performance? yes, but I would assume it will be negligible.

[Former Community Member]

Hi @Kashif Kazi some additional comments:

Item 2) its probably a good idea to delegate authentication to CAS/LDAP vs having 2 sets of credentials. This would be a more simpler approach.

Item 4) You can have the DNS for apis eg. api.company.com point to the Apigee gateway & lock down access to any other components (Backend services, CAS etc), good idea to put them behind firewalls so they cant be accessed directly but only through Apigee Edge (You can whitelist gateway IP addresses or we also support 2 way SSL to secure communication between Apigee Edge & your CAS & backend services)

Item 5) Developers wont get access to the CAS token unless you specifically send it to them as part of the OAuth access token. You can still associate the CAS token with the generated OAuth access token but not share it with them.

[#8]

It sounds as if you're trying to leverage access tokens and client key and secret from an Identity Provider. Here's a basic step by step of an API Proxy that could help you with this requirement. http://apigee.com/docs/api-services/content/use-third-party-oauth-system. @sgopalam@apigee.com this very similar to the use case that we discussed in the past. Feel free to weigh in.