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.

.

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!

.

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.



.

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!


.

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

.

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 

Done!

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". 

.

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

.

2FA API

One Identity recently launched Starling Two Factor Authentication, a SaaS-based solution.

It solves the password problem without the capital costs or increased infrastructure management that you might incur with traditional on-premises solutions. With an easy to use dashboard for administrators and flexible authentication options for end users, Starling Two-Factor Authentication enables organizations to quickly and easily verify a user’s identity.

Starling Two Factor Authentication is actually based on Authy.

The nice thing about Authy is that it provides REST APIs which is useful for application integration which requires 2-Factor authentication. e.g OneTouch API, Phone Verification API. 

Cool stuff!

.

More APIs integration with IRAS (Singapore Taxman)

I blogged about More and more APIs exposed by Ministries. Yesterday, I read about Taxman calls on Grab, Uber drivers from Straits Times.

Dodging the taxman will become more difficult in the gig economy, as going cashless allows for better electronic tracking of payments. And the taxman has his sights next on Uber and Grab drivers.

An Iras spokesman said: "To simplify tax filing and ease compliance for our taxpayers, Iras continually seeks ways to explore initiatives with third parties and platform providers to automate the transmission of income information directly into our tax systems."

What's the end state?

Definitely a gateway (Grab/Uber) with gateway (IRAS) integration with Grab/Uber automatically submitting drivers' earnings directly to IRAS - same as the one we are implementing right now for an Insurance agency in Singapore.

.

API Design - Initiate Optimize

In my previous blog, I talked about a customer of mine who worried about too many calls hitting her API Gateway.

As we have seen quite a number of API deployment gone live, these are typical worries. One has to treat this type of project as a Full Lifecycle API Management journey. API deployment cannot be treated as a one-off project.

The worry that the customer had is where we will usually Initiate Optimize as illustrated in the diagram above.

• Optimize the way the application requests for a OAuth2 access token by reusing an established access token
• Optimize by increasing the OAuth2 access token timeout 

Are we able to foresee every possible performance issue that will surface after go-Live? Very hard.

Why? APIs are exposed to consumers in the public. There are no fixed usage pattern. We can usually optimize based on past experience, but usually tweaking is required after go-Live for each deployment.

.

Client Credential Grant Type and Refresh Token

I was in a discussion with a customer today and we talked about how to reduce the number of calls to Kong API Gateway.

This particular API Gateway is only for internal applications communication, thus Client Credential Grant is configured on each endpoint.

The main concern was that prior to each endpoint call, the internal applications have to make a call to request for a OAuth2 access token. This will be 2 calls to the Kong API Gateway per endpoint.

But, hey, if this is a setup of internal applications communication, we can increase the access token timeout. And it is programming best practice to reuse established access token, rather than to get a new access token prior to each endpoint call.

There's a choice.

The APIs are not exposed to the public. If the application teams within the same company cannot cooperate with one another, there's nothing we can do about it.


The customer continued to probe further: "Can't we ask the application team to use the OAuth2 refresh token to exchange for a new OAuth2 access token?"

But... this is Client Credential Grant type. There's no refresh token generated.

Refresh tokens are only provided when retrieving a token using the Authorization Code or User Credentials grant types.


.

Stock Trading RESTfully

IG Group is a UK-based company providing trading in financial derivatives such as contracts for difference and financial spread betting and, as of 2014, stockbroking to retail traders.

I just came across their trading platform and discovered that they have "API-exposed" their trading system via IG Labs.

This is cool for experienced traders who want to apply their own trading algorithm before they make a trade (either open or close) for automated trading. 

I am seeing this as a trend moving forward...

I searched the local trading securities in Singapore. I think most have just poured their champagne by delivering their Mobile trading platform. 

None has exposed their trading platform as APIs yet. But surely the day will come... just a matter of time!

.

API Development - Not Engaging Early Enough

I was reading a blog from Nordic APIs - 5 Frequent Developer Community Mistakes (And How to Fix Them).

I could relate quite closely to one of the mistakes - Not Engaging Early Enough.

Many of us make this mistake frequently. We thought we have a great API to launch, but we actually do not really know what the market is looking for!

A new development process is suggested:

• Idea : Generate initial tech design documents. 
• Think: Add some context to those documents, make them more digestible, explain motivation, come up with NDAs. 
• Explore: Send to a small subset of developers for feedback. 

THEN

• Build
• Launch
• Tweak

Great reminder!

.

More and more APIs exposed by Ministries

The trend is pretty clear these days - ministries in Singapore are encouraged to expose more and more APIs for external entities to consume, in particular organizations/companies.

This will save huge amount of human hours if manual tasks like Form Submissions can be automated. Yes, we have a labour crunch here in Singapore. We do not have enough local people in our workforce. Thus automation is key going forward!


My team is currently designing APIs for one of the financial institutions in Singapore. This week, we have a new request to integrate with Inland Revenue Authority of Singapore (IRAS) for Commission Income Information Submission.

The current process of submission is very manual.

It requires a person to download a program (Offline Validation Program - OVP) from IRAS to validate a XML/Excel file. Once validated, one has to log in via SingPass (Singapore Personal Access) and then manually upload the XML/Excel file to IRAS portal.

The new API service allows applications to directly submit Commission Income Information to IRAS , thus eliminating the need to download and validate using OVP and login to IRAS portal for submission.


.

Microgateway

“CA Microgateway is a great example of how more and more of the tech industry is realizing that APIs are not just how we integrate tools and apps, APIs are the new way of doing business and building new revolutionary technologies,” Said Geoff Domoracki, Founder of API World.

CA Microgateway has received a 2017 API Award for the category: Microservices APIs. While the product is still in beta, its ability to deliver aggregation, orchestration, security and management to microservice architectures impressed the judging panel for API World this year.

Kind of strange to me that a beta product can win an award. :)

So what is really a Microgateway? Why do you need one if API Gateway has been recommended over the years?

I could not find a good explanation in CA documentation. Well, since it is still in beta, I would expect there are not too many real use cases to talk about.

Google Apigee has better explanation.

• Reduce latency of traffic for close proximity services 
• Keep API traffic within the enterprise-approved boundaries because of security or compliance purposes 
• Continue processing messages if internet connection is lost

Features of Google Apigee Microgateway:

When to use Microgateway over traditional Enterprise Gateway?

This is the most important slide. 

Summary:

• API has to be light-weight. (otherwise, how do you classify yourself as microservice?)
• Few APIs to a gateway 
• No complex mediation rule (aka no heavy-duty processing)
• Small scale (100+ APIs per sec)
• Internal API for app-to-app integration 

.

In-place Upgrade vs Greenfield Upgrade

There are different school of thoughts when it comes to upgrade - In-place vs Greenfield (or Side-by-side). 

In-place Upgrade could mean 2 things:
U1. Executing an upgrade wizard that comes with the software
U2. Install the latest version on another disk partition, separated from the current version that is Live.

I refer to the former in this context.

When cost is involved, most will go with In-place Upgrade as a greenfield upgrade requires another identical set of hardware and operating system. This, I totally agree.

When customers have cost constraint, I will usually recommend U2 for major version upgrade. Minor version upgrades are usually bug and security fixes. I will usually use approach U1. No brainer.


Now, there are 3 groups of specialists who will give you different opinions when you ask them if it would be wise to perform upgrade using approach U1:
S1. Product Engineers
S2. Product Presales
S3. Product Professional Service Engineers or Service Delivery Partners


Now, if the wizard is written by you (S1), would you say "No, U1 is not the better approach"? This group of specialists also tend to assume that the product is deployed out-of-the-box with no or minimal customization. My foot. Now, even if they agree that the product is highly customized, I come to realize that QA of the wizard is usually not well carried out. There are few too many edge cases that they would not be able to think of in their own labs. (can you blame them? no. product engineers are usually the ones who do not like to meet and interact with customers. thus they do not get to know the business-world requirements and they definitely do not have the full picture of how the products they developed are deployed in real world)

What would S2 say? You know the KPI of a presales? Can you say that the product that you are selling so hard has no seamless upgrade wizard in front of your customers? This group of specialists has the least hands-on. They are really good in sweet talking and reading documentation. You ask them to set up the software from scratch. They look at you like you are an alien. "Dude... there's a VM with everything installed. Come on...". Asking S2 deep technical/operational/migration questions is usually a waste of time, unless you do not mind hearing white lies. (well, to be honest, they do not want to cause harm. just that they do not have the right hands-on experience)

S3 is the group of specialists that are doing the shit job, even to the extend of implementing empty promises from S2 that are totally out-of-scope. S3 usually tells the hard truth, which customers would not like to hear at times. "well, I have paid tons of dollars for this piece of software? I don't care. You get it fixed to what was being promised". However, they have years of hands-on and have seen many types of deployments. They also have many years of migration experience. (ok, I have also seen delivery partners that are incompetent. there was once a big customer in SG asking this delivery partner how to extend their current SSO infrastructure to support multiple domains. to our surprise, a consultant from this delivery partner suggested to set up a totally new environment to support this new domain. omg! most SSO products can support cross-domain single sign-on these days. It's a out of the box feature)


Azimuth has been in the Identity business for a long time and we have performed numerous upgrades for customers. Softwares, especially IDM and SSO, are "fragile" animals. IDM products are usually highly customized, while SSO products are usually deployed as a farm of server nodes to handle huge traffic.

SSO solutions usually have low tolerance for downtime. When in-place upgrade is adopted, there are many questions to ask. 

1. How do you upgrade to a new major release then? Say there are 10 nodes to upgrade.
2. How do you upgrade to a release that is at least 2-3 versions apart? 
3. How do you upgrade the underlying configuration store, if any? Say there are 4 nodes to upgrade.
4. How do you ensure protected applications work as before? Say at least 50 applications are involved which belong to 10 application teams? 
5. How do you ensure customized codes work as before? 
6. How do you ensure deprecated functions that are replaced with new functions in the new release work as before? 
7. How do you ensure new features requested by customers work as promised? 

How do you complete the above all within a narrow downtime window of 5 hours (12am to 5am)? Nearly impossible.

A presales will never take the above into consideration when being asked about which is the better upgrade approach. Stick with product documentation is always the right approach. Crap.

One would also question why would there be challenge and surprise if well-conducted UAT is carried out prior to Production upgrade. From experience, I can conclude that most UAT environment is not identical to Production. Seldom, less than 10%. Why take the risk and bang your balls for that tiny 5 hours window? It's not worth taking the risk. Rolling back, investigating why, perform another round of upgrade, activating the same whole village of application teams to perform end-to-end testings are just not worth the trouble. In fact, reputation is at stake.

Some customers are also one of the kind. They are not technical enough, yet they want to have a say. So they go around asking opinion from various sources. A service delivery partner does not come from the Product organization. The customers will take the advice from the Product Presales over what the Service Delivery Partner recommends. "How can I not believe what XXX has said? XXX is from the same Product organization. He sure knows better than you."

Oh, really? 

Now, who is performing the upgrade? What if something goes wrong during upgrade? Whose responsibility is that? To ask a service delivery partner to perform upgrade again at a fixed cost (we practice fixed cost in Asia) is really not a fair deal.

Approval Anywhere

These days, Approval Anywhere seems to be a must-have feature in product development.

One Identity recently launched Safeguard - a Privileged Access Management (PAM) solution.

The biggest feature is what One Identity is calling “Approval Anywhere,” a cloud-based workflow to securely approve session or password requests from any device.

CA has a similar "Approval Anywhere" feature from the CA Identity Portal.

It comes with an OOTB Mobile Web application. No configuration is required to enable and configure this mobile application. The application can be browsed through any mobile browser. CA Identity Suite will automatically detect that you're browsing from a mobile device and redirect you to the mobile application.


This feature helps a lot during presentation, especially to the C-level. Believe me. :)

.

Exposing APIs in the Financial Services

I met up with a number of financial institutions over the past few months. You know these are established companies with long history and their IT infrastructure is strong and big.

Out of 10, 9 of them will have SOA (Service Oriented Architecture) in place. Then they'll have ESB (Enterprise Service Bus) solution to support their SOA initiatives. Web services are everywhere. Integration with internal and external parties are also common.

Why would they need a API Management then? Below are some of my slides:

Security, Sandboxing and Scalability is my most-used tagline.

Yes, they could have deployed their own DIY solutions, as the concept of API Management is not something new. Honestly, if your team is highly technical and security-conscious, there is really no need to buy a ready-built APIM product out there.

It's a matter of time to market and where you want to spend your time in.

Do you want to spend most of your time in your core business? Or do you want to split your precious time in managing the security risks and scalability issues when your APIs are exposed?

It's a choice - $ vs Time.


Below is a statistics showing the target audience of exposed APIs in the Financial Services:

The goals of deploying a APIM solution in the Financial Services section as illustrated below:

Interesting.

CA API Developer Portal UI Customization - Part II

CA Developer API Portal aims to build and monetize a broad and effective digital ecosystem, enterprises must make it easy for developers to find and use APIs. It enables developer communities and support app marketplaces with essential capabilities for management, security and monitoring.

For the developer portal to be useful, the forums must be a go-to place for developers. The UI has to be intuitive and modern to use.

Our designers continues to wow us. They have converted the original look-n-feel of the forum, which looks like a piece of software developed by engineers, into an UI where information nicely presented and easy to navigate.

Well done.

.