Thanks! It looks like this solution might work for us. On Sat, Jul 25, 2009 at 3:07 PM, Paul Trevithick <[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]> 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]> > 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
