Hi everyone.
Can you help me clarify this?
I have always used hardware tokens with AM 8.4.
Now we have moved to software tokens sid 820 (always with AM).
What are the methods of distributing the software token to the users?
The most practical thing would be to have it managed by individual users independently, perhaps with a QR code as they are working from home.
Also, I've heard of AMIS: does this improve the user-case of user enrollment? in which way?
Thanks so much
Shanelle
SecurID Access Prime AMIS and the Prime Self-Service (SSP) and Prime Help Desk Admin Portals (HDAP) provide a rich set of methods and workflows for distributing software tokens, mobile authenticators and on-demand authenticators. Software token distribution via CT-KIP URLs or QR codes are the most effective and secure way to distribute tokens. These can be accessed by end-users in the Prime SSP or via custom web portals invoking REST web service calls to the Prime AMIS framework. Prime also supports a wide variety of other authentication and administrative workflows.
Is your goal to build software tokens into an existing portal, or looking to provide a richer, branded self-service experience?
Thanks for the reply.
The goal is to give to the users the possibility to let them manage indipendently the enrollment of their device.
The idea is to use the AM product features without making customization.
I know that CT-KIP URLs and QR codes are the most secure way to distribute tokens. It is mandatory to have AMIS?
What changes if I use or not use AMIS in this standard use-case?
Thanks
Shanelle
You could use the AM Self-Service Console (SSC) as long as you are fine with AD userID+password as the authentication method. If you want a richer, brandable experience with advanced onboarding and multiple authentication methods, you'll want Prime. I'm sure there are many other workflow automation, help desk streamlining, rich branding features you may find helpful built into Prime which extends the base AM platform. For small customers (<2,500 tokens) the SSC and Security Console are typically adequate.
Authentication Manger has self-service capabilities included. To facilitate CT-KIP (QR Code) provisioning, you will want to deploy a Web-Tier server in the DMZ to allow users to access the self-service console and scan QR codes remotely.
AMIS / Prime is professional services delivered add-on 0that comes with enhanced customization capabilities notably branding and workflows. The built-in self-service console in Authentication Manager offers limited authentication options whereas the AMIS / Prime package offers a much wider range of configurable workflow / authentication options such a one-time access url (sometimes called a magic link) or a help-desk driven challenge-response flow.
In short, AMIS / Prime is not required for self-service / QR code scanning but it provides additional capabilities and customization to address unique requirements that are not included with the out-of-the-box Self-Service Console.
AM Prime is a robust tool, but is not part of the AM server, so if your goal is to let users self-manage their software tokens without making customization you could consider using the build in Self Service Console, SSC instead of the Self Service Portal, SSP from AMIS AM Prime. SSC does not have near the features of SSP, but you can allow users to authenticate with their LDAP password, request and then import a software token into their device; Smart phone or PC and get on with their work.
The big considerations are;
1. Secure Delivery of the software token is best achieved with CTKip encryption, basically a one time use URL that a user either clicks, or it can be converted into a QR-Code so that a Phone could scan the URL (PC based software token application cannot scan QR code, only click or copy and paste URL).
a. importing a software token .sdtid file, even a password protected one, is not as secure as a CTKip delivered software token.
b. Device ID binding can add a layer of security, but requires Admin intervention, can't really be done with Self Service
c. If you use CTKip, it is arguable that you do not need device binding, but if you are using .sdtid files, it is arguable that for some level of security you should include device binding or have strict limits on how and where the file can be imported. It is Not considered a secure practice to email these these .sdtid files all over the place, they can be copied, You'd want some kind of control for email encryption, maybe only within your Corp LAN or something like that.
2. If you want your users to access this Self Service Console from the Internet as opposed to coming into the office or through a VPN, you will need a Web Tier, which is kind of a reverse proxy app the runs on either your Windows or RHEL server and sits in your DMZ. Smart phones may not typically authenticate to a VPN, more like they might access your corporate wireless. So your PC based Software token app could work without a Web Tier if that PC VPNs into your Corp LAN, you do not need a web tier because the PC is virtually on your internal network. But if your PC VPNs in, logs onto the SSC and requests a soft token for a Phone, even if the QR code displays on the SSC, the CTKip URL will not work on the smart phone because the smart phone without a web tier because only the PC is on the VPN, the smart phone is not.
The good news is, once you get end users to jump through all the hoops of getting their software token imported, you can extend the life of that software token and not have to import another token when the first token expires. This assumes users keep their same phone.
AM Prime is a robust tool, but is not part of the AM server, so if your goal is to let users self-manage their software tokens without making customization you could consider using the build in Self Service Console, SSC instead of the Self Service Portal, SSP from AMIS AM Prime. SSC does not have near the features of SSP, but you can allow users to authenticate with their LDAP password, request and then import a software token into their device; Smart phone or PC and get on with their work.
The big considerations are;
1. Secure Delivery of the software token is best achieved with CTKip encryption, basically a one time use URL that a user either clicks, or it can be converted into a QR-Code so that a Phone could scan the URL (PC based software token application cannot scan QR code, only click or copy and paste URL).
a. importing a software token .sdtid file, even a password protected one, is not as secure as a CTKip delivered software token.
b. Device ID binding can add a layer of security, but requires Admin intervention, can't really be done with Self Service
c. If you use CTKip, it is arguable that you do not need device binding, but if you are using .sdtid files, it is arguable that for some level of security you should include device binding or have strict limits on how and where the file can be imported. It is Not considered a secure practice to email these these .sdtid files all over the place, they can be copied, You'd want some kind of control for email encryption, maybe only within your Corp LAN or something like that.
2. If you want your users to access this Self Service Console from the Internet as opposed to coming into the office or through a VPN, you will need a Web Tier, which is kind of a reverse proxy app the runs on either your Windows or RHEL server and sits in your DMZ. Smart phones may not typically authenticate to a VPN, more like they might access your corporate wireless. So your PC based Software token app could work without a Web Tier if that PC VPNs into your Corp LAN, you do not need a web tier because the PC is virtually on your internal network. But if your PC VPNs in, logs onto the SSC and requests a soft token for a Phone, even if the QR code displays on the SSC, the CTKip URL will not work on the smart phone because the smart phone without a web tier because only the PC is on the VPN, the smart phone is not.