Rally does not have specific types of users. Users are distinct by their permissions level but they all are of the same type and obey the same security policies. There are no designated users as Service Accounts in Rally.
If your subscription has Password Policies in effect then they apply to all your subscription users who authenticate by Rally's native authentication method.
We need to distinguish between two types of subscriptions:
- Subscriptions using Advanced Security and Administration.
- Subscriptions not using Advanced Security and Administration.
Advanced Security and Administration is an Rally's module that ingrates your subscription into your corporate Single-Sign-On gateway or solution. Normally such corporations have their SSO define and control the password policies across the corporate. As such, there will be no reason for you to enable Rally's own password policies. Rally allows the option for 'SSO-with-exceptions' which allows you to 'white-list' a number of Rally users who will authenticate using Rally's native authentication (and not through your SSO). Considering no Password Policies defined then these will not expire. In this way you achieve the purpose of treating these exception usernames as if they are Service Accounts for the purposes of executing non-interactive integrations as mentioned earlier.
However, if your Subscription is not using Advanced Security and Administration , then it is using Rally's native authentication. In this situation there isn't a way to distinct the Service Accounts from the rest of the users. If you define password policies then they will apply to all. Your Service Accounts (that is these specific usernames) will expire as any other account. Rally will alert of the upcoming expiration in the 7 days prior to expiration as it does for all usernames:
Keep in mind if the Service Accounts will actually expire then they will stop working until a new password is set. In that event also their Api Keys will stop working until the usernames are back in Active status. Remember that api-keys belong to a given user-account and always operates under that account. If an api-key is used on behalf of a 'service account' then it will take a seat in your subscription since it actually is working on behalf of a real account (even if it's a 'service account'). You may want to consider this fact when deciding how many service-accounts to allocate or use. On one hand minimizing the service-accounts and running all integrations under the same account will use less seats, but then you will not be able to distinguish between your connectors and sources if all executed under the same account. So, it's something for you to consider.
Considering all of that, you may want to consider setting the email address field of these Service Accounts to a joint email address so many in your team will receive the alerting emails and take action prior to the expiration.
- Rally itself does not handle Service Accounts distinctly.
- Rally's native password policies apply to all its users who use native authentication.
- With the Advanced Security and Administration module you are deferring the password policies handle to your SSO solution, hence you may use Rally's Exceptions to white-list a few usernames, allow them to use native authentication, you will opt not to create native Rally's password policies, so these usernames will never expire and are getting treated as if they are Service Accounts.
- If your subscription only uses Rally's native authentication then your Service Accounts will expire in accordance with your password policy, at which point they will not be able to authenticate until a new password is set. That includes their Api Keys. You will want to make certain you set the "Email Address" field of these usernames, set them up to receive email notifications so that you can avoid the expiration.