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. 

Exactly. 

The test would work, but if you have an array of multiple items, element 3 could be null in theory. This problem could really be addressed via using a List rather than Credential.... For some reason passing null to a "Credential..." creates an array with a null value!