Community
Participate
Working Groups
Many plugins are using Platform.*AuthorizationInfo() API to store passwords and other sensitive information. It would be useful to provide a common UI for managing this information, similar to Team / CVS / Password Management UI. Maybe even just promote this UI to the platform/workbench level.
Please note that auth info API is used by plugins in different ways. Most common uses are like this: Platform.addAuthorizationInfo(new URL(getUrl()), AUTH_REALM, AUTH_SCHEME, map); Platform.addAuthorizationInfo(DEFAULT_URL, getUrl(), AUTH_SCHEME, map); In first case we have auth info that has platform url handler (i.e. http) and second case is usually used for non standard urls (I think Team/CVS plugin is using this variant). DEFAULT_URL, AUTH_REALM and AUTH_SCHEME are usually some plugin-specific constant values. I.e. Mylar is using something like this: String AUTH_SCHEME = "Basic"; String AUTH_REALM = ""; URL DEFAULT_URL = new URL("http://eclipse.org/mylar");
I could sketch up some UI and implementation, but the problem is that Platform does not allow to query keyring content.
I suspect that, before work can proceed on a password management UI, there are some security issues that would need to be addressed in the keyring itself. I think the best approach would be for you to log a bug against Platform/Runtime requesting support for this UI. This should get the discussion started on what shape the keyring needs to be in before work can proceed on a general password management UI.
Eugene, did you log a bug against Platform/Runtime as suggested by Michael in comment #3? If so, can you mark this bug as dependent on that one, or if not, can you open one? I don't want any relevant runtime requirements to get lost in this bug...
FYI, platform runtime/equinox is intending to move towards JAAS for managing identity/passwords. This likely won't happen for 3.3, but hopefully in the next release. For this reason, we don't intend to augment the rudimentary keyring support provided by the platform, and recommend avoiding creating additional UI infrastructure around it.
John, the UI meant to be built around Platform.getAuthorizationInfo() and such methods. I hope you are not planning to deprecate those?
Yes, those methods will likely be deprecated once we have a suitable replacement. Don't panic, this won't be happening in 3.3. Having a common UI for identity management is still a good enhancement request, but we should not commit to anything that relies on the existing platform authentication API, which is quite weak compared to API such as JAAS.
(In reply to comment #7) > Yes, those methods will likely be deprecated once we have a suitable > replacement. Don't panic, this won't be happening in 3.3. Having a common UI > for identity management is still a good enhancement request, but we should not > commit to anything that relies on the existing platform authentication API, > which is quite weak compared to API such as JAAS. I am not arguing that. But current platform auth API is used quite widely (meaning it will be quite painful to deprecate) and yet suffer from the absence of unified management UI...
I don't see this happening on the old API, but this can be revisited once Equinox moves to JAAS
The functionality was added in 3.4 RC releases but was removed prior to the final release due to concerns over the security and ease of use. I think two developments are needed to put this back: 1) We need to come up with some generic extensible concept of "account" on top of the secure storage 2) The secure storage should have additional lock for OS-integration providers. The concern was that is, say, Windows integration is used and there is a UI to see contents of the secure storage, then a passer by cas press a few keys and see a list of passwords. To satisfy both worlds, secure storage at the time of cretion coudl allow an extra password to be created that woudl have to be entered before user can see information it stores in the UI (The rudimentary UI is available on the secure sotrage preferences page.)
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.
