| Summary: | Support for user authentication | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Oleg Besedin <ob1.eclipse> |
| Component: | E4 | Assignee: | Project Inbox <e4.runtime-inbox> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | cvgaviao, erdal.karaca.de, laluz, ob1.eclipse, pwebster, tjwatson |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 328277, 330675 | ||
*** Bug 327978 has been marked as a duplicate of this bug. *** There should be a new ICapabilitiesService that determines whether the current LoginContext/authenticated subject (JAAS) has access to a specific UI element:
boolean hasAccess(String type, String instance, String actions);
E.g. if you need to check whether the current authenticated user has access to a part:
@Inject
ICapabilitiesService service;
@Inject
void createContents(Composite parent) {
boolean hasAccess = service.hasAccess("WORKBENCH_PART", "com.example.parts.mySpecificPart", "OPEN" );
if (!hasAccess) {
Label l = new Label(parent, SWT.NONE);
l.setText("You are not allowed to access this part!");
return;
}
//... create the UI elements
}
Where there will be a new JAAS Permission type that can handle all eclipse specific UI elements, such as:
- parts(, editors), wizards, commands, ...
To grant those privileges to a specific user, the policy file could look like this:
grant principal the.used.PrincipalType "MyPrincipal" {
permission org.eclipse.e4.core.capabilities.EclipsePermission "WORKBENCH_PART/com.example.parts.mySpecificPart", "OPEN";
};
Note: The policy file syntax only allows one string parameter to be passed to the Permission in the permission rule, i.e. we have to encode the type+instance to be contained in a single string ("type/instance"), else we have to define one permission type for each UI element (WorkbenchPartPermission, WizardPermission, CommandPermission, ...).
---
The capabilities service could rely on the OSGi UserAdmin service to manage users/roles which itself relies on JAAS for authentication. Though, I am not sure if this service will fit the needs, this is to be determined...
|
We'd like to have concepts of users, roles, and, possibly, permissions to be available in e4. The user would either login into an RCP application, or have its credential confirmed via a trusted 3rd party (OS, Kerberos, LDAP). The RCP application then will make user's information and associated roles available to the application code. {OS | Custom} [JAAS] Login -> User -> {RCP | 3rd party} User's roles -> {RCP | 3rd party} User's Permissions The system should support temporary escalation of privileges, probably done via set/reset of additional privileges. The elements that are likely going to be needed to accomplish this: - OS integration JAAS login module - Startup screen login dialog - Standalone login/logout/switch user dialog - Status bar indicator / trigger for the login/logout dialog - API classes that support User, Role, and Permission data - extendable way to retrieve Role and Permission data based on the User Constraints: - We'd like to see this work being integrated with JAAS and Equinox Security bundles - The User / Role / Permission description that we'll end up with should make sense in the Javascript world Optional: - UI that can be used to manage User / Role / Permission