Options for softtoken distribution to iOS iPhone
I'm looking to find the easiest way to distribute a softtoken to an iPhone user. Does anyone know? I'd prefer the QR code but I think that's only available via the Self Service portal (which is not an option for us as the iPhones are off the network and cannot connect to the LAN).
I know of several methods but each seems to have its own downside:
- Creating QR code with the TokenConverter.jar file
Cumbersome process involving Java etc; some Helpdesk employees find the command line too difficult or don't have Java installed so can't use the util. Are there easier/better ways to create/issue QR codes?
- Emailing the SDTID file
This trick doesn't seem to work (anymore) for iPhone users; the file arrives OK but cannot be "opened with RSA app". This used to work fine but stopped a while ago; does anyone if/when this will be fixed? Am I doing something wrong?
- Emailing a CTF link
This works OK, but it's not a clickable hyperlink in the iOS Outlook or Gmail app so users have to manually copy/paste the link into the RSA app. WhatsApp does format it as a clickable hyperlink but we can't use that for end-user distrubution. Any way to make these links clickable/accessible through email?!
How are others dealing with these issues? Am I overlooking the obvious here or is everyone using a Self Service portal with internet access? Is it not possible to have the Self Service portal generate the same QR codes as when using the TokenConverter.jar file (so that they can be opened without direct access to the SS portal)?
- Community Thread
- Forum Thread
- RSA SecurID
- RSA SecurID Access
- Token Auth
- Token Authentication
- Token Authenticator
- Token Authenticators
What version of Authentication Manager are you using? It sounds like you're still using sdtid files to distribute soft tokens instead of using the Web Tier feature of AM 8.4 to distribute soft tokens via CTKIP. Using the Web Tier in a DMZ, you can set it up to present a QR code (the web tier can enable secure internet-facing Self Service) to the user which the RSA Token App will use to directly download the token into the app, or email them the link the QR code represents. You will need to create software token profiles (in the Security Console) and add them to the profiles available to end users in the Self Service Settings.
Hi; thanks for the reply. We are in fact using the latest 8.4 but we're running without DMZ web tiers. Our company is afraid of "exposing systems to the internet", especially when it comes down to this particular system which is seen as the gatekeeper to everything else. I realize this is more "a feeling" than rational, but it is what it is.
So you're right - our primary method for distribution to Android is still SDTID; for iOS, we're struggling as you can see above.. Does this mean that, without internet facing SelfService, we're stuck with copy/pasting CTF links from emails..? How do other customers handle this when offering Self Service isn't an option?
You can use the Web Tier, without enabling the internet-facing Self Service, as a secure CT-KIP server and distribute the CT-KIP link, which is more secure and has other advantages over using the sdtid files. When the user clicks on the link, the RSA Token App is invoked to connect to the WebTier (via a public URL you establish that goes through your firewalls on 443) which itself reconnects to the Primary on a different port, then the Token App and the Primary have a brief conversation to install the token on your device. It's a one-time operation and there is no artifact (like an sdtid file) left behind to be protected.
By the way, the Gmail issue is really that, a Gmail problem -- invoking an iOS app (like the RSA Token App) from a link requires that the link have a certain format that includes how to invoke the app (thus the software token profiles back in the AM Security Console) and that is registered with the device. Installing the RSA Token App registers our link handler format (begins with "com.rsa.securid://" with iOS on your phone, but Gmail so far does not recognize such non-standard protocols, even if the phone allows them. It's a known thing; lots of programmers have complained to Google about it. If you read the same email in the default Apple email client it should work fine.
Thanks for elaborating on that! Unfortunately it's not just Gmail - I only used that as a test. Our company enforces the Outlook app on iOS for business email and it too has issues with recognizing the "com.rsa.securid://" links; it doesn't make them clickable.
I like the option of exposing the CT-KIP delivery service but I'm still afraid that A) security would be against anything to do with placing RSA components on the internet and B) things like that take time (getting a new server, external IP, design, firewalls etc - it's a large company and things are slow).
I was hoping for something I could use without having to build extra infrastructure components but I'm guessing that won't be possible? Are the options I outlined in my opening post all that is available today? We're using the Device GUID to bind SDTID to single devices so I'm not too worried of leaving them behind, however that method unfortunately fails for delivery to iOS..
Thanks again for the quick feedback; much appreciated!
Thanks, I indeed like the QR solution a lot, however, I'm struggling to make the converter process available to all different service desk employees; they have high turnover and since it's not a cookie cutter solution, I can't get them to adopt it. It requires Java, command lines, placing files in specific locations etc and somehow it's "easier" for them to just email CTF links. I personally liked the .exe converter better but it's not capable of creating QR codes.
Hi - the SecurID Prime Suite includes a self-service portal (can be internal-facing; no DMZ) that can use that softwaretokenconverter java executable at scale, all automated. QR code then distributed any way you want. There is a price for this add-on component and is delivered by RSA Professional Services. However, the larger benefits can include reducing the reliance on Helpdesk (saving time/resources) AND provides a range of other awesome things.
Very interesting, thanks for highlighting that option - I indeed wasn't aware of that! Will check internally on what options we have; I'm sure that "no internet, no DMZ" feature will get bring smiles to their faces 😉