Your Questions Answered – Imprivata OneSign for Healthcare

Thanks again to everyone who joined us for a very interactive webinar to learn more about how Imprivata OneSign can save clinicians more than 15 minutes per day. We had more than 40 questions during our Q&A session and have provided a transcript below of the most common questions.

Q. Does OneSign handle password expiration rules?

A. Yes. Within the system you determine how you want that application interaction to happen. When the backend system prompts for a password change, the policy will kick in and it can do everything from filling in the old password, to letting the user create a new password and submitting it. The new password is remembered and we continue to use it. We can also completely automate that process on behalf of the end user and randomize the password. From a policy perspective you can allow the user to see what the password has been changed to or you can completely hide it. Over time you can reduce down to that single primary authentication modality, where the users’ credentials to their applications are randomized.

Q. What happens if a user loses their I.D. badge?

A. There are a variety of options to handle that issue. If they’ve lost it and can’t get it replaced immediately, the emergency access components will allow the user to use knowledge-based Q&A questions to satisfy the authentication requirements. There are certain policies that affect this. For example, if the client is online or offline there may be more questions in one mode vs. the other. Once a user is issued a replacement card, the system has the capability to re-enroll the card under their identity without having to call the help desk or any resetting on the server side.

Q. What about RSA token use?

A. It is fully supported within the OneSign appliance (whether physical or virtual) and has a full blown RADIUS server built in, which allows us to do third party integration like remote access devices or RSA tokens for example. We front end the RSA token server and then allow you to use it anywhere OneSign is supported. So for a desktop, virtual desktop, or remote access, OneSign acts as the middle man and proxies it. It’s the same with secure computing tokens and any others out there. Vasco tokens are built natively into the system so the back end controller is embedded in the appliance. If you chose Vasco or are already using them you can leverage those directly in OneSign without extra pieces.

Q. Is OneSign FIPS compliant?

A. Yes, we are FIPS compliant. The default server is not a FIPS alliance but we do have a FIPS version that includes Thales nCipher hardware security modules built in to the appliance for FIPS mode.

Q. What happens if the OneSign server goes down? How do we get into the application if we no longer know the password?

A. Everything will work even if the OneSign servers are unavailable. There is an offline mode that can be set based on policy to either be good for a certain number of days or not allow it at all. The client side has the knowledge-based questions and answers whether it’s on a desktop or a web browser, and the user can lookup application credentials if allowed by policy.

Q. Does the OneSign agent have to be installed on the client?

A. It depends on the access method. In most cases there is an agent that gets installed on the workstation whether it’s the endpoint or the virtual desktop. In the case of OneSign Anywhere, that is our agentless solution. You can deliver the same access to the applications and manage the SSO components without a client or agent.

Q. Does the user need to have an email address to use the self-service password manager?

A. No. When a user starts using the system it takes them through a question and answer enrollment process and then for them to utilize that they can use the Windows credential providers or a web browser.

Q. What desktop operating systems are supported?

A. Everything Windows: XP, Vista, 7, 32 and 64 bit, 2003, 2008, embedded. We are reviewing Linux-based devices and zero clients as well. We just released support for Teradici-enabled zero clients to support zero client No Click Access^® on VMware View desktops. We also support Citrix XenDesktop and XenApp as well.

Q. You said it works with “green screen.” We have two different terminal emulators for these. Therefore, would this work with our AS400/i-Series and AIX sign-on?

A. Absolutely. Depending on what client you’re using determines the integration path. If the editor is HLLAPI enabled that makes it easier. Even if not we can support single sign-on into those emulators.

Q. Can you customize the login prompt?

A. Yes, it is flexible and hospitals can add their own logo or custom graphic if they chose to.

Q. If a user is logging in via VPN and forgets his/her password, how does he reset his password from outside of the DMZ?

A. It depends on what kind of password. If we are talking about a domain or LDAP directory password, that can be handled by the web based self-service component which is a knowledge based question and answer process.

Q. Does OneSign include role based authorization and role mapping into backend databases?

A. We are looking at that as something we may add next year. Currently we leverage the credentials from the primary directory and synchronize those into OneSign, essentially correlating the application credentials as we learn them against that primary account within our internal directory.

Q. Can you access more than one application with the SSO access? If so, how does it know which application you want to access?

A. You can support as many applications as you need. An administrator will go through this process of profiling each application once and pushing out these profiles to anyone that is allowed to utilize SSO. This is a key difference between OneSign and some of the other systems that are out there. OneSign does not allow users to get access for SSO to anything until it is explicitly defined by the administrator that they can have access.

Q. Can OneSign work with web based/Cloud based applications?

A. Based on the way our technology is built we don’t need to do any integration on the back end of the application itself. That allows us to deliver single sign-on services and manage the credentials for those applications for any application you can access.

Q. Does One Sign interact/interoperate in a SharePoint environment?

A. Yes, OneSign can deliver SSO service into SharePoint.

Q. Do you support Macs?

A. Yes, with our OneSign Anywhere product. This is our agentless mode of support.

Q. What does your licensing model look like?

A. The system is licensed on a per name user basis. For example if you have 200 users you would buy 200 seats of OneSign. You always get two appliances to start that are active all the time. One appliance supports over 25,000 users. The appliances are included in the price of that user license. Please contact sales@imprivata.com for specific pricing questions.

Q. Applications require multiple types of fields. For example, some require three pieces of information on one screen, and some require multiple pieces of information one screen at a time. How do you handle those differences?

A. We can fully support any type of login screen or screens. Based on the workflow of the application login process, OneSign can determine how to profile it. For example, if an applications requires the user to input a username, password, plus three or four additional pieces of information, that administrator “trains” OneSign to fill in all of those fields with the correct information.

Q. We have a number of systems that require the use of passwords. They all expire after 90 days. If a user's active directory account expires at the 90-day mark, how does your solution work with that password expiration?

A. It would depend on the exact workflow. Once the password is in need of change we will either change it or facilitate that change. For example, for a domain password, we will fill in the old password based on the authentication you use, whether its user name, password, proximity card, or biometrics. The user will create a new password and then it will be stored and used in the future for validation against the domain. We can automate that password change or allow the user to change it themselves based on the policy. There is no requirement for one to happen before the other. As we encounter them in the workflow we will do whatever the policy tells us to do.

Q. What fingerprint reader manufacturers do you use?

A. We support about 95% of the readers out there in the market. We deliver support for Validity readers, UPEC readers, AuthenTec readers, and almost all other manufacturers. Just about any embedded fingerprint reader in any mobile device such as tablets and laptops are almost all supported today. One of the nice things about the way we handle biometrics is we have all the matching and processing that happens on the back end within our server. This allows us to be very flexible with the devices that we support. We allow you to fully mix and match the readers that we support and roam from one device to another even if it may have a reader from a different manufacturer.

Q. Can the web camera for walkaway be used for user authentication?

A. Today Secure Walk-Away is only available for automatic locking of the workstation when the user departs. Once an authenticated session starts up, re-authentication can happen after the user departs and comes back.

Q. Do you manage the access for users through OneSign or continue to use ad group policiy memberships once you deploy?

A. When we do the integration with the directory we leverage specific groups, users, or groups of machines and map that into our policy. Therefore you would continue to manage the users within the directory itself and OneSign would apply policy based on group membership or even down to a specific user if you want it to be very granular.