- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
RSA Token Extension
How is this handled on the client application side? My understanding on token extensions is that there is no need to touch the end user's software token device in any way when a token is extended on the server, however I have a question about this.
The software token app (for example on Android) knows that the token is about to expire and it is alerting the user about an upcoming expiration. There is no communication between the AM server and the end user authenticator, so when I extend the token of the server what happens on the end user's authenticator? If anything? Will the app continue to warn of impending expiration but will just continue to work after hitting the expiration date "magically" (from the end user's perspective)? I'm assuming if I don't need to touch the end user's device the software token on the app is never "informed" that it's lifespan has been increased. Just looking for some guidance on what the end user experience is like so I can properly prepare my user base.
- Tags:
- Authenticator
- Authenticators
- Community Thread
- Discussion
- extendable
- extension
- Forum Thread
- RSA SecurID
- RSA SecurID Access
- SecurID
- Software Token
- software token for android
- Token
- Token Auth
- Token Authentication
- Token Authenticator
- Token Authenticators
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The end user must have installed a token that came from an 8.2 or higher version first. These tokens will have an expire date on the user side, of Dec. 2035. Then you can just keep extending these tokens on the RSA server side up until Dec 31 2035.
If the user sees an expire date on their device sooner than 2035, then they did not get that token from an 8.2 system, the system must have been below 8.2 when they got the token distributed and installed. The solution is distribute the token to them again, [delete the first token from the device and install the newly distributed copy], as long as the RSA server is 8.2 or higher when that occurs, and it will have a 2035 expire date on the user device, and a normal 'paid-for' expire date on the RSA server.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Or, does the fact that the app is warning of expiration simply mean the token that user has was issued pre-AM8.2 and is not extendable?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Mason,
I have moved this thread to the RSA SecurID Suite" data-type="space so that you can get an answer to your question.
You can post future questions and discussions directly to that community by clicking on the Ask a Question or Start a Discussion button on the RSA SecurID Suite" data-type="space page.
Thanks,
Jeff
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The end user must have installed a token that came from an 8.2 or higher version first. These tokens will have an expire date on the user side, of Dec. 2035. Then you can just keep extending these tokens on the RSA server side up until Dec 31 2035.
If the user sees an expire date on their device sooner than 2035, then they did not get that token from an 8.2 system, the system must have been below 8.2 when they got the token distributed and installed. The solution is distribute the token to them again, [delete the first token from the device and install the newly distributed copy], as long as the RSA server is 8.2 or higher when that occurs, and it will have a 2035 expire date on the user device, and a normal 'paid-for' expire date on the RSA server.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you Edward, that's exactly what I was looking to find out.
