Community
Participate
Working Groups
The current JAAS/Equinox integration work allows LoginModules to be added to the JAAS login sequence. It would also be desireable to have extensible login modules, so that plugins could provide Principals and/or Credentials to existing login modules (e.g. the one(s) used for Eclipse).
There are org.eclipse.equinox.security.auth.credentials: IPrivateCredential IPublicCredential IRole And org.eclipse.equinox.security.auth.credentials.spi: CredentialsFactory The idea would be that once login is successful, Subject gets public/private credentials added (and logout removes corresponding credentials). Scott, is this what you are looking for? (For example, see AskLoginModule)
(In reply to comment #1) > There are org.eclipse.equinox.security.auth.credentials: > > IPrivateCredential > IPublicCredential > IRole > > And org.eclipse.equinox.security.auth.credentials.spi: > > CredentialsFactory > > The idea would be that once login is successful, Subject gets public/private > credentials added (and logout removes corresponding credentials). > > Scott, is this what you are looking for? > > (For example, see AskLoginModule) > Hi Oleg, > The idea would be that once login is successful, Subject gets public/private > credentials added (and logout removes corresponding credentials). > > Scott, is this what you are looking for? Yes, partially. I would also like to be able to add Principals for a given subject (e.g. Subject.getPrincipals().add(ID)). The use case for this is that we would like to add ECF IDs (an interface that extends Principal) to the principals associated with a Subject, before the Subject is set to read only (which typically happens in the login commit I believe). The use case for us is this...we use IDs to represent 'accounts/identities' on remote services...e.g. xmpp://slewis@ecf.eclipse.org. It would be nice to be able to add Principals/IDs/accounts via Subject.getPrincipals().add(ID) and add credentials via Subject.getPrivateCredentials().add(String) both during login (i.e. before these are set to read-only via Subject.setReadOnly()). Then, at later times (e.g. when user initiates a download from site requiring authentication, we would be able to get accounts and associated credentials via the Subject.getPrincipals(<class>) and Subject.getPrivateCredentials(<class>). These could then be used to authenticate to a given target upon IContainer.connect(ID targetID,IConnectContext connectContext) Does this make sense? Is there a better way to accomplish this same goal? BTW, where is AskLoginModule?
Moving to security component.
Scott, I think this is a good point to look at the integration of Eclipse Higgins/identity management framework into ECF. Having extension points around the LoginModule is not a good solution for security reason. I will ask Matt to provide you the contact information of Higgins folks. -eric
(In reply to comment #4) > Scott, > > I think this is a good point to look at the integration of Eclipse > Higgins/identity management framework into ECF. Having extension points around > the LoginModule is not a good solution for security reason. I will ask Matt to > provide you the contact information of Higgins folks. > > -eric > I don't think that Higgins is going to meet the needs here. I'm familiar with the project (and was a committer some time ago). We have our notion of identity (e.g. org.eclipse.ecf.core.identity.*) and I don't see Higgins' work as fundamentally replacing that (Higgins can/could be an org.eclipse.ecf.namespace provider, but I haven't got them to make that implementation as yet). I would like to understand what you mean by 'not a good solution for security reasons'. I understand that the eclipse extension registry has no security associated with it (i.e. any bundle can add extensions, and hostile bundles could add an extension that defeated security), but couldn't this be dealt with in some other way? (e.g. require that the contributor be a framework extension, or use OSGi services instead of extension registry...or something else?)
(In reply to comment #5) > (In reply to comment #4) > > Scott, > > > > I think this is a good point to look at the integration of Eclipse > > Higgins/identity management framework into ECF. Having extension points around > > the LoginModule is not a good solution for security reason. I will ask Matt to > > provide you the contact information of Higgins folks. > > > > -eric > > > > I don't think that Higgins is going to meet the needs here. I'm familiar with > the project (and was a committer some time ago). We have our notion of > identity (e.g. org.eclipse.ecf.core.identity.*) and I don't see Higgins' work > as fundamentally replacing that (Higgins can/could be an > org.eclipse.ecf.namespace provider, but I haven't got them to make that > implementation as yet). > > I would like to understand what you mean by 'not a good solution for security > reasons'. I understand that the eclipse extension registry has no security > associated with it (i.e. any bundle can add extensions, and hostile bundles > could add an extension that defeated security), but couldn't this be dealt with > in some other way? (e.g. require that the contributor be a framework > extension, or use OSGi services instead of extension registry...or something > else?) > When you add Principals/IDs/accounts via Subject.getPrincipals().add(ID) via Subject.getPrincipals().add(ID), wouldn't other bundles be able to retrieve password credentials through Subject?
(In reply to comment #6) <stuff deleted> > > When you add Principals/IDs/accounts via Subject.getPrincipals().add(ID) via > Subject.getPrincipals().add(ID), wouldn't other bundles be able to retrieve > password credentials through Subject? Yes...but couldn't other bundles (that are installed/running) just access the SecurePreferences associated with another bundle (and get to the credentials that way? That is, I believe that I could write a plugin that gets the CVS passwords stored by the CVS provider and do stuff with them...even without getting them via the Subject. If there isn't a way to prevent this (for trusted bundles anyway), then I don't see the access to the Subject credentials as any more dangerous. If I'm misunderstanding please LMK.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
