Hi,

I tried to change the lifetime of a security token issued by Geneva Server following the instructions given here:
http://social.msdn.microsoft.com/Forums/en-US/Geneva/thread/ddd9d3b4-47de-43ec-91cb-b634c9524dfb

These instructions work pretty well as long as token lifetime is shortened. But if I try to extend token lifetime beyond 10 hours, the new settings are just ignored and the default lifetime of 10 hours is applied again.

Is this behavior due to a bug? Or is it a (security) feature?

Regards,
Holger Kuehner

Hi Holger,

Server caps the lifetime of to max lifetime (10 h). I think the issue is that PowerShell allows you to specify greater lifetime than 10 h. I am interested to know, what's your scenario and why you want to generate token with longer lifetime?

Thanks
Mieszko

Hi Holger,

Server caps the lifetime of to max lifetime (10 h). I think the issue is that PowerShell allows you to specify greater lifetime than 10 h. I am interested to know, what's your scenario and why you want to generate token with longer lifetime?

Thanks
Mieszko

Hi Mieszko,

thank you for your reply.

My intention is to use delegation for tasks like backup. From the time when the user logs on to the service, her token should be saved and used as a bootstrap token every time the service is scheduled. In order to implemenent it this way, the bootstrap token has to live for at least several months.

I'm very interested in suggestions how to solve this problem. Maybe token renewal could be the way to go? Does Geneva Server support token renewal yet?

Regards,
Holger

Thank youfor providing details. Geneva Server does not support renew contract. I don't quite understand the reason for bootstrapping the token. I am not sure why the backup service needs to make decision about the user identity after several months since authentication. Is it because of a need to extract user attributes, authorization?

Let me construct a scenario for the sake of clarity: A GetAccountBalance service returns account balances to authorized users. A backup service periodically queries GetAccountBalance service in order to save snapshots of account balance or to send notifications about changes. The user should be able to log on to backup service and configure polling intervals and notification thresholds. From this time on, backup service must be able to access GetAccountBalance service acting as the user.

One solution could be that when the user logs on to backup service, the user token is saved as bootstrap token. Every time the backup service wants to query GetAccountBalance service, it has to get a delegate token from the STS. Therefore, it embeds the bootstrap token in RST.

This solution seems impossible when using Geneva Server as STS, since it is not able to issue a token to the user that can be used as bootstrap token even after a few weeks. Are there other ways to tackle the problem?

Thank you. I am trying to collect more information for your scenario. I will pass all the information to product unit.With status as it is now, it's not possible to extend token lifetime beyond threshold or renew the token. It's also required to have client token for delegation scenario.

Hi Mieszko,

I'm very interested in the results of your investigations and would be glad to hear from you in near future. Thank you for your answers so far.

Regards,
Holger Kuehner