webMethods API Portal guide
webMethods API Portal is electronic storefront of your great APIs. This is the place were you market the APIs that you have developed to the external world. Since API Portal is going to be an external world facing component as part of your API platform, it is a must to safeguard your application and its users from the potential threats coming from outside. As part of this article, we will explore different ways to mitigate these potential risks to safeguard our user base. We will have a high-level overview of the below list of topics:
- Strong password policies
- Enable expiring passwords
- Enable account lockout
- Enable Multi factor authentication(MFA)
Strong password
The password for any access must be unpredictable and hard to crack. Some general recommendations for having a strong password
- require a minimum password length of 8 characters.
- the use of both upper-case and lower-case letters (case sensitivity).
- inclusion of one or more numerical digits
- inclusion of special characters, such as @, #, $
BUT again above one is just a general recommendation from a Wikipedia source. The password policies differ from one organization to other for various reasons. Being a
administrator of a tenant, webMethods API Portal allows you to define really comprehensive password policies that suits for your organization needs. To define a password policy for your organization, login to your user management console (UMC) and switch to "Configuration" view. As an admin you can define/enforce:
- maximum/minimum number of characters in password that each registered users should have
- Minimum number of lower/upper case characters that password must have.
- Minimum number of special characters that password must have
- You can also define the list of allowed special characters
- You can also define the list of allowed special characters
- Minumum number of numers that password must have.
Expiring passwords
It is always a recommended good practice to change your password periodically. BUT again you see contradicting views from various security experts regarding the 'password expiry' policies. Some may argue, having a unpredictable strong passwords are good enough, you really dont have to mandate the users to change their passwords for every xx number of days.
webMethods API Portal allows organization admin to optionally enable the password expiry policy. With this setting the admin can also define the length of the password lifetime. As admin you can define a rule like, "every registered user must change the password for every 90 days".
Account lockout
The Account lockout setting determines the number of failed login attempts that will cause a user account to be locked. A locked account cannot be used until you reset it or until the number of minutes specified by the account lockout duration policy setting expires.
Attempt limit
Defines the threshold for the number of failed login attempts before the account lockout happens
Lockout duration
determines the number of minutes that a locked-out account remains locked out before automatically becoming unlocked
Lockout Counter duration
Determines the time frame for couting invalid login attempts. If you have this value set to 60 minutes(and attempt limit defined as 3), if users tries 3 wrong attempts in this 60 mins then account will gets locked. If user tries 2 wrong attempts in 60 mins and if he tries 3rd attempt at 61 mins then his account will not be locked as the Reset Account Lockout Counter After is for 60 mins , and After 60 mins the counter will be reset and he will get 3 more chance now 
.
Multi Factor Authentication(MFA) - really a Two factor
The most common method of authentication is the username and password. This may seem like two factors, but both the username and the password are 'what you know' components and the username is generally public knowledge or easily guessed. So, the password is the only thing that attacker has to predict.
Two-factor authentication requires using two different methods, or factors, to provide an additional layer of protection. Typically, two-factor authentication involves using either 'what you have' or 'who you are' in addition to the standard username and password ('what you know').
Terminology
Security token
A security token is a physical device(RSA SecureID) or piece of software(Google Authenticator) used during user authentication. The token generates the one-time passwords used by the user to prove his identity during the authentication process. UMC requires the use of an asynchronous dynamic password token in which a timer is used to rotate through various combinations produced by a cryptographic algorithm. The token and the authentication server must have synchronized clocks.
One-time password
A one-time password is a password that is valid for a single login attempt only. Users need to enter an OTP during login in addition to their normal account password. OTPs may be generated by a security token that the user carries or be send to the user using an out-of-band channel such as SMS/email.
Authenticator secret
An authenticator secret is a secret key unique to each user used for generation of OTPs. If a token is used to generate the OTPs then users need to configure this secret in their token.
Time step
Is the time slot in which an OTP is valid, e.g. 60 seconds.
Configuration Settings
Clock skew interval
Specifies the clock skew in number of intervals. One-time passwords (OTPs) that are within the valid range [currentTimeStep - clock_skew, currentTimeStep + clock_skew] are permitted. This is defined in milliseconds.
Excluded users
There are certain users we use for Machine-Machine communication. For ex, we configure a user of a API Portal in API Gateway to be able to publish the APIs from API Gateway. We would like to exclude these users from providing a OTP secret for a Machine-Machine communication. You can configure the list here as comma separated values.