Wednesday, December 20, 2017

Federation vs Web Access Management (WAM)

This question has been asked repeatedly over the years. I came across this link while I was searching for OpenID Connect feature in CA SSO 12.7.

Federation has the following advantages: 

  • Many applications can handle federation directly out-of-the-box, such as SAP, SharePoint, WebLogic. These applications accept assertions. 
  • A direct connection to a centralized server is unnecessary. A federation request always goes through the asserting party to get the generated assertion. After a user gains access to content on one server, the user returns to the federation hub and gets redirected to the next server. Only if the user session times out at the hub does the user have to reauthenticate. 

These advantages make federated partnerships better for an environment where sites are remote, inaccessible, or under third-party control.

Single Sign-On (WAM) has the following advantages:

  • Transactions are faster because there are fewer browser redirects. 
  • Provides centralized authorization and auditing. 
  • Direct links can exist from one web server to another in a network without the user going through a centralized hub for assertion generation. 
  • Offers timeout management. 
  • Applications are independent of a remotely initiated transaction. 

These advantages make WAM single sign-on better suited to an environment with sites that are under your control, such as internal data centers.


Tuesday, November 21, 2017

CA API Policy Manager - Revision History

CA API Policy Manager is the user interface for the CA API Gateway. It is used to construct web service and XML application policies, manage policy users, configure identity bridging, and configure, audit, and monitor the CA API Gateway. Pretty useful tool, though it's a "eighties" thick client. 

It has tons of functions though, and they become quite useful at times. Today, a developer in my client's side changed something to an existing API, but couldn't tell me exactly what he has changed. 

Well ... typical. Vendors are paid to spend time to discover/explore/clean-up what has been messed up.  

Luckily, the Policy Manager has a Revision History to each API.

It can show a history of the changes made. What's best is one can choose 2 historic APIs and make comparisons.

What's even better is it can pin-point which assertion(s) within the API has been modified. A visual output in RAW XML format can even be shown.

This function saves me big time!


Thursday, November 2, 2017

API Slug

 I was playing with Tyk since they are offering 50.000 API calls / day FOC. What can you ask for?

While creating a test API, I came across a term "API Slug". What's that?

API IDs are internally unique but hard to remember. These are not useful for users, so you can replace them with a slug.

I find this developer friendly, as opposed to GUID as shown below.

Tyk was built because other open source API Gateways in the market come with dependencies and bloat, attempting to be too many things to too many people. Tyk is focused, simple and does one thing well - protecting your API from unauthorised access.

Another open source product ... let's see how long they will stay being open source.

These days, I make it a habit to fork frequently. You never know when the source will be closed.

When $ comes and put on your table, let's see whether or not you'll stay true to yourself - the original dream of building a whole-class open source product for the open source community.

We are all human beings.


Saturday, October 28, 2017

Should we allow modification of EULA?

In CA API Developer Portal, when an API consumer wants to subscribe to a published API, he/she has to accept the EULA (End-User License Agreement). I believe this is the same for all other products out there.

So a customer of mine asked me the other day why he is not able to edit the default EULA that comes with the portal installation. Note: these are random texts (as shown below) and customer wants to go-live, thus he needs to modify the EULA proper.

He also created a new EULA and tried to change the default EULA to this new one. But he was not allowed to do so.

Bug with the product? No.

We found out that he has already created applications and assigned some APIs to these applications. Now, when a consumer adds an API to his/her application, he will be prompted to accept the Terms and Conditions as stipulated in the EULA.

Once accepted, from an audit point of view, this particular EULA shall not be changed by another party. As such, CA API Developer Portal implements this "disabled" function.

I think this is a great feature. It covers the benefits of both parties - API Publishers and API Consumers.

I have seen other software vendor asking customers to sign a paper-form EULA. But within the EULA, it points to a hyperlink with more terms and conditions. In one case, a contract was signed in year 2016. In Sep 2017, customer went to the site and realized the terms and conditions had been updated (latest modified date was May 2017) without notice.

This is bad practice!


Friday, October 27, 2017

API Design & Implementation Tips

I was attending CA Partner Momentum held in Singapore this week. We had John flying in from Australia to conduct the event for us.

Some tips from John which I think are useful for field staff like us.

  1. Recommend agile approach 
  2. Collaborate with customer - get 1 dedicated person from customer's side to work 
  3. Minimum viable product 
  4. Select a simple API 
  5. Generate test case first (POSTman) 
  6. Use Gateway to emulate backend 
  7. Share test cases with client as early as possible 
  8. Show progress against test cases 
  9. It's ok for customer to change their mind (embrace change - but ask for something in return) 
  10. Leverage API Academy for questions around strategy


Friday, October 20, 2017

CA API Developer Portal Sign Up Form - Organization Name missing!

A customer of mine wanted to add Organization Name (make it mandatory also) to the Sign Up form. Just a few days prior to meeting with him, I was playing around with CA API Developer Portal. I do remember that Organization Name is actually available, but it was displayed as Title on the Sign Up form.

I confirmed via the admin console.

The issue is with the naming “Title”. It should be “Organization Name”. The UI should display Field Name, instead of Field ID. This could be a bug with the product.

This field can also be made mandatory by clicking on “Make this field required?”. I tested and it works in my labs.

With regard to the "bug", CA Support came back with a solution. 

Navigate to /xml_content/phrasepacks/v3. Edit dashboard-display.xml.

*** look out for title and description keys and make changes there.
*** make sure you are in common form phrases section 


Now, customer also asked how he can rename the wordings "I accept the disclaimer".

It's actually residing in the same XML under the tag "AcceptedDisclaimer". 


Tuesday, September 26, 2017

What is Serverless APIs?

Yet another buzz word - Serverless, when it actually means Cloud Platform / PaSS. 

- No servers to provision or manage
- Scales with usage
- Never pay for idle
- Availability and fault tolerance built in

With it, comes yet another term ... Serveless APIs.


APIs vs Microservices

I talked about the new trend in API - Microgateway and the often used buzzword "Microservices".

This slide says it all ... courtesy of Matt McLarty from API Academy. #APIWorld17