One other avenue to consider - in the AIR selector, the authentication module has been nicely separated from the rest of the application, so that it can be fairly easily extended to use other kinds of authentication materials. Currently, it uses username + password + 'serialized key', where the serialized key is activated once using an OTP delivered via email, and then stored in the local machine using AIR's ELS, which in turn uses window's DPAPI.
I could envision an alternate scenario for shared workstations or a 'kiosk mode', where instead of authorizing a permanent 'serialized key', use the OTP directly to authorize a single access, and don't store the credentials locally. The OTP could be delivered via email as it is currently done, or other channels (SMS, voice telephony, hw token) could be added. =TC ________________________________ From: [email protected] [[email protected]] On Behalf Of Tsvika Rabkin [[email protected]] Sent: Saturday, July 25, 2009 5:52 PM To: Paul Trevithick Cc: Oren Cohen; higgins-dev Subject: [higgins-dev] Re: Selector questions Thanks! It looks like this solution might work for us. On Sat, Jul 25, 2009 at 3:07 PM, Paul Trevithick <[email protected]<mailto:[email protected]>> wrote: Tsvika, Just so you have the whole of our thinking on this, here’s a bit more detail about where we are headed with Higgins: The user’s selector is “serialized” with a key unique to that selector installation (this is the “something you have part”), then the selector is secured with a “master” password (this is the “something you know” part). If a person’s computer is stolen, they can use any other device to de-provision that computer so that it no longer works. Azigo has developed this capability and will be contributing it to Higgins very soon. If a specific card requires yet stronger security, the card’s IdP can require yet other factors to also be required. The card IdP could require its own password, a USB token device, etc. If/when we can tie the serialization key to a local TPM chip or equivalent on mobile device, we can harden this approach even further. --Paul On 7/24/09 4:09 PM, "Tsvika Rabkin" <[email protected]<http://[email protected]>> wrote: Paul, Sharing some thoughts on physical device vs. hosted services: Physical device: 1. The identity provider creates real world trust by providing cards on a physical device. 2. There is strong "two factor authentication". Something you have (card/key) and something you know (PIN). 3. If the device is lost or stolen, the feedback is almost immediate. The security risk can be minimized by quick notification to the IDP that issued the managed card. 4. Devices cost more than hosted service. However, USB keys are very common and the IDP/user can load the cards to the key he/she already own. Hosted I-Card service: 1. Hosted I-Card service is easy to synchronize and backup. 2. Cost efficient. 3. Cards are not stored on the selector. Good for shared machines. 4. 5. The "master" pw is a bit of concern, especially regarding to "leakage" of managed cards stored on the hosted service. Maybe there's a hybrid solution. A possible scenario: * The user stores the cards (self issued and managed) on the hosted service. * * Suppose that the user has at least one managed card (issued by the same IDP that issued one of the cards stored on the hosted service), stored on his/hers personal machine or an external device. * This card can be used to login to the I-Card hosted service. In this case the cards are backed up and synchronized regularly, but no un/pw is involved. * In this scenario, usage of shared machines still demands an external device. Tsvika On Fri, Jul 24, 2009 at 9:37 PM, Paul Trevithick <[email protected]<http://[email protected]>> wrote: Tsvika, I’m trying to understand your requirements. You wrote to me privately: * Most of the clients in this [your] project are windows XP based, and the login is done via browsers using un/pw. The computers are shared workstations with common windows account for all the students, making card portability a necessary demand * * In order to avoid the usage of un/pw for card provisioning, it seems that the preferred solution will be to carry the cards on a physical device such as usb key or smart card. For security reasons the cards should not stay on the selector, but vanish when the external device (usb/smartcard) is plugged out. For Higgins 1.1 we are working on an Adobe AIR selector that uses a hosted I-Card Service. No cards are stored locally, so there is nothing to delete. Cards are stored on the server and fed to any selector that wants/needs them. Could that work? Now it IS true that for this to work we require a “master” username/password to authenticate the user to the hosted service. Is this what you are trying to avoid in your second bullet above? It seems to me that an external device will cost more than running a hosted I-Card Service and some people think that the external devices themselves should be protected by a PIN etc. to prevent others from using them directly. And in this case both solutions require a password/PIN—so they are equally bad/good in that regard. --Paul
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
