SSO-disabled service can never be granted ST

If the `ssoEnabled` flag is set to false for a given service, the CAS authentication flow never passes the login screen. User is always forced to present credentials, but can never actually get to the application and validate the ticket.

The behavior is:

1. If credentials are presented and an existing authentication exists, ignore the `ssoEnabled` flag because the user already presented credentials.
2. If an existing authentication does not exist, meaning no credentials were presented by the user, force the user to present credentials if `ssoEnabled` is false.

The problem with the 1st case is, credentials are always treated as absent. They are always null. This pull fixes that by retrieving the credentials from the flow, and makes sure what is retrieved is correct and non-null when needed. On the first try when credentials are actually presented by the user for the TGT, credentials are properly passed down. On 2nd tries when the TGT already exists, credentials are forced to be null and cleared up so the authentication check can fail and user forced to authenticate again. 

I don't know if in practice it happens, but it's best to assume that it does given that the API allows for it. In fact it is there by design to allow for MFA-related functionality.