FormCred Issue : Multiple logins

[K.Anurag]

Hi Team,

 

In one of our environment, we recently migrated from 12.5 Policy store to 12.6.

Few of the application were kept pointed to the existing 12.5 store and few were pointed to the new 12.6 store.

We synced the key-store for both env by taking an export from existing store and importing it into the new one.

SSO was working fine.

 

After sometime not all but few of the application on new 12.6 store started giving an issue.

Our authentication scheme is a form based login page with web agent residing on apache and policy server pointing to 12.5 and store 12.5

The target application which is SM protected after passing the login page couldn't consume the login.fcc and the login page just gets refreshed.

Nothing specific in the agent error log except below.

Could you please help ?

Is it something which is specific to key store or may be it is a completely different issue ?

 

Environments are as below:

 

Old Env:

Webagent R12 >>>Policy Server R12.5>>>Policy Store R12.5 (acting as a Key Store too).

New Env:

Webagent R12 >>>Policy Server R12.6>>>Policy Store R12.6 (acting as a Key Store too).

 

Old Env and New Env >>> Key Store is Synced. Hence SSO Works.

 

FCCCompatMode :  yes

IgnoreExt : .fcc is present

 

In the Old Env Policy Server R12.5 generates agent keys.

In the New Env Policy Server R12.6 doesn't generates agent keys.

#Working application Web agent trace Logs

[CSmSessionManager::EstablishSession][No plugins responded, returning SmNoAction.]
[IsResourceProtected][Resource is protected from cache.]
[CSmHttpPlugin::ProcessResponses][Processing IsProtected responses.]
[DeleteCookie][Deleted cookie 'FORMCRED'.]

 

#Non-Working application Web agent trace Logs

[CSmSessionManager::EstablishSession][No plugins responded, returning SmNoAction.]
[IsResourceProtected][Resource is protected from cache.]
[CSmHttpPlugin::ProcessResponses][Processing IsProtected responses.]
[ProcessCredentials][Plugin interface SmNoAction.]
[ProcessRequest][CredentialManager returned SmNo or SmNoAction, calling ChallengeManager.]

 

Regards,

Anurag

[Sharanabasava Kariyappa]

As you mentioned, Old env is generating keys then it might have generated new set of keys which are not updated in new env. 

Kindly export the keys and verify them once.

 

regarding your issue, Are you facing issue only for SSO? or even for normal login in new env?

Please elaborate more on the issue.

 

Thanks,

Sharan

[Rick_Siek]

I suspect that Sharana's comment is correct. My recommendation is that you export your R12.5 key store data and install it into standalone key store. Remove the key store data from both the 12.5 and 12.6 policy stores. Point both the 12.5 and 12.6 environments at the standalone key store. Also, switch from having one 12.5 policy server doing key updates to having one 12.6 policy server doing the key updates.

Using a standalone key store makes doing upgrades easier and avoids issues like the one you are having.

[K.Anurag]

Sharana Rick_Siek ,

Thank you for your suggestions.

 

If I keep a single key store, this issue doesn't comes, which obviously points the issue towards the difference in the keys in both the stores as you suggested.

I have compared both the stores' Agent Keys OIDs and they are exactly the same (Though there is a difference in the encrypted key values).

 

I am unable to understand the agent keys concept and the rollover part here.

In AdminUI, under Agent Key Management, use static agent key is configured. So , I understood that the agent keys in the Key store will remain static unless there is a manual rollover.

Since there is no manual rollover, and it was only one PS which was generating the keys from before, there shouldn't have been any changes in the keys at all.

Is there any default rollover which happens ?

Would request your help in understanding the Agent Keys concept.

 

Regards,

Anurag

[emmle02]

Hi Anurag,

 

Refer : Tech Tip : CA Single Sign-On : Data Protection, Key Management,Configuration & Common Issues 

 

Regards,

Leo Joseph.

[K.Anurag]

Thank you for the Tech Tip link.

 

But in our case, static agent key is configured.

Will the keys rollover/change even if static key is configured or will it remain the same for indefinite period of time ?

If the keys will not change then the mentioned issue should not come right, as the agent will be able to encrypt/decrypt ?

 

Regards,

Anurag

[Peter Burant]

This problem could occur if you have a domain mismatch between the credential collector and the URL used to request the protected resource.  Since you have FCCCompatMode enabled, when the user submits credentials the credential collector will place the credentials into a FORMCRED cookie and redirect the user to the protected resource.  The agent protecting the resource decodes this cookie and submits the credentials to the policy server for authentication.  If the domain set in the FORMCRED cookie doesn't match the domain of the protected resource, the resource agent will redirect the user back to the login page since the browser will not present a cookie set for Domain A when making a request for Domain B.

 

This could of course manifest as an intermittent problem if the users can use multiple DNS names when requesting the same resource, otherwise it would be hard to explain why this problem does not seem to occur when a single key store is used.  If the keys were not the same between 12.5 and 12.6, no applications would have SSO between the two environments.

A Fiddler or other type of HTTP trace will allow you to track the FOMCRED cookie to see if a cookie domain mismatch is causing this problem.  If no mismatches are observed, then more focus can be placed on the key/encryption infrastructure.  Static keys will not roll by themselves.  Keys are encrypted with the Policy Server encryption key by default, but the Management Console gives the option to use a manually entered encryption key when the Key Store is marked as external to the Policy Store (this option is not widely used, but does change the encryption context for agent keys).

 

I hope this helps,

Pete