Token management between AFM and State Manager

[Nikunj_Padhiyar]

AFM asks State Manager to create a token to store the state data. AFM then makes the request to read the same token and sends the delete request as shown in below logs:

 

 

2018-05-04 16:13:16,692 [[ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'] DEBUG toksvr.client.SimpleTSClientImpl(403) -> Sending creation request to https://<state-manager-domain-and-port>/arcotsm/servlet/creation/eacf12468d05378d
2018-05-04 16:13:16,692 [[ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'] DEBUG toksvr.client.SimpleTSClientImpl(406) -> Token data sending for creation is : {"TsToken":{"StateData":"rO0ABXN......cHEAfgBEcHBw"}}
2018-05-04 16:13:16,694 [[ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'] DEBUG toksvr.client.SimpleTSClientImpl(317) -> Wrote the data: {TokenData={"TsToken":{"StateData":"rO0ABXNyADJj........cHEAfgBEcHBw"}}}
2018-05-04 16:13:16,722 [[ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'] DEBUG toksvr.client.SimpleTSClientImpl(549) -> Sending read request to https://<state-manager-domain-and-port>/arcotsm/servlet/tokens/eacf12468d05378d

2018-05-04 16:13:48,301 [[ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'] DEBUG toksvr.client.SimpleTSClientImpl(549) -> Sending read request to https://<state-manager-domain-and-port>/arcotsm/servlet/tokens/eacf12468d05378d
2018-05-04 16:13:48,388 [[ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'] DEBUG toksvr.client.SimpleTSClientImpl(457) -> Sending delete request to https://<state-manager-domain-and-port>/arcotsm/servlet/removal/eacf12468d05378d

 

 

 

Can anyone help me to know how AFM identifies to which user this token is mapped? when this token needs to be used and when to delete it ? Is it soemthing written in the state data(encoded format above) which AFM sends to State manager?

[munla06]

After SiteMinder disambiguates the user, SiteMinder makes a CreateToken call to StateManager by passing in the UserDN and other info as a JSON. As a response, TokenID will be returned. This will be passed to AFM as a request parameter when the call redirects to the AuthLanding url. AFM makes a Read and Update Token call to StateManager component to retrieve the Token and also update the Token Data. When a Token is retrieved via TokenID, token contains all required information for the user. Delete token happens after the Token was validated by SiteMinder or after the token was expired (every token has a set validity that is configurable).

1. SiteMinder makes a Create Token call with UserDN and other info.
2. AFM makes a Read Token call to get the UserID and other info.
3. AFM makes an Update Token call with the Adv Auth authentication status along with the info retrieved in Read Token call
4. SiteMinder checks the authentication status and deletes once validated.

 

Hope this helps..

[Nikunj_Padhiyar]

Thanks for the reply Lakshmikanth.

 

I understand the flow mentioned by you. 

 

- Siteminder(Shim) asks to create the token to State Manager.

- State Manager creates token and gives to Shim.

- Shim sends this token to AFM for multi factor authentication.

- AFM checks the status of token with State Manager. 

- Here AFM gets reply from State Manager about the token data. AFM reads the token and I can see the below log which is fine:

 

2018-05-07 22:18:12,428 [[ACTIVE] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'] INFO  integrations.frontend.LifeCycleStateData(681)  -> 707098077: Log message from Shim: Authentication successful|[e-mail] |20180507211811.765.d0c50077

 

Now my concern is, here AFM makes a call to State Manager to create a new token which has information of the State as shown in the logs(again mentioned below):

 

2018-05-04 16:13:16,692 [[ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'] DEBUG toksvr.client.SimpleTSClientImpl(403) -> Sending creation request to https://<state-manager-domain-and-port>/arcotsm/servlet/creation/eacf12468d05378d
2018-05-04 16:13:16,692 [[ACTIVE] ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'] DEBUG toksvr.client.SimpleTSClientImpl(406) -> Token data sending for creation is : {"TsToken":{"StateData":"rO0ABXN......cHEAfgBEcHBw"}}

 

Here the value of StateData is encoded. So, I need to understand, if AFM is going to State Manager to create a "NEW" token(as token id is different than the one which Siteminder sends to AFM initially) with the State data, how AFM knows to which user this "New" token is associated as there are no associations found? And when will AFM calls to delete the token? I understand there is always an expiry of token, but here AFM makes call to delete it explicitly.

 

I guess it might be something with the encoded state data. However just want to be sure, as not able to find this behavior in documentation.

 

Hope this clears my question.

[munla06]

When AFM updates the Token with Adv Auth status, there is an option to regenerate a new Token or use the same TokenID. By default in AFM, it will generate a new TokenID. Using this new TokenID SiteMinder makes a read token call, checks on the Adv Auth authentication status.

 

Thanks,

Lakshmi.

[Nikunj_Padhiyar]

Ok. So by default AFM creates a new token ID to update the information which should be our configurations. 

 

Now, how AFM will identify that this new token is associated with which user? 

 

Also, I didn't understood how Siteminder will make a call to read token in between the 2FA journey.

What my understanding is, as soon as the controls is with AFM, it will make sure to do all the configured actions like risk evaluation, OTP generation and verification and then post the updated token to shimfinal.fcc. Now, Siteminder/SHIM can ask for token information to State Manager. 

[Stephen McGilligan]

Hi Lakshmi,

 

You mentioned "there is an option to regenerate a new Token or use the same TokenID. By default in AFM, it will generate a new TokenID". Can you confirm this and where this option is configured? We raised a support case and the feedback from engineering is that the regeneration of the token isn't optional.

 

There also seems to be a lack of information about the security concern the regeneration of the token is addressing.

 

Thanks,

Stephen

[Nikunj_Padhiyar]

I guess I got answer.

 

The token which is used by AFM is just to store the state data. This is not the actual token of the user which State Manager created initially.

 

So when AFM gets the request, it knows the state of the request and gets to know what needs to be done next. For instance, AFM gets to know that OTP is verified from the State Data(token), so next step is to ask User if (s)he wants to make device Public/Private.

 

After getting the token, AFM asks SM to delete the token. A new token will be again created if the state data is changed.

This is not a product default behavior. We have customized to have the session persistence in AFM.

 

So summarizing, in a journey, AFM create/read/delete the token many to times just to know the state of the request. This is not the actual token which is being deleted.

 

Thanks,

Nikunj