Bug 327978

Comment 1 Erdal Karaca 2010-10-16 08:35:42 EDT

Created attachment 181035 [details]
UAA services API

This is a draft version. Changes will be made and committed to https://dfruits.dev.java.net/svn/dfruits/branches/v2.0.0/com.dfruits.security

Comment 2 Erdal Karaca 2010-10-25 03:37:58 EDT

Created attachment 181614 [details]
UAA API, JDBC Impl, Test Suite

This is for reviewing purposes.
Import the plugins from the attached archive.
I would be glad if someone could comment on this solution and/or if this is the way e4 could realize UAA services...

The archive consists of the UAA API, a JDBC (db model may be specific to derby) based implementation and a junit4 test suite (consisting of 36 test cases)...
Currently, ~60% of the test cases fail...

Comment 3 Erdal Karaca 2010-11-02 16:19:51 EDT

Created attachment 182249 [details]
All tests in test suite succeed

Comment 4 Erdal Karaca 2010-11-02 16:30:20 EDT

Now, this is a good starting point for evaluating the UAA services:

- setup a derby database
- see com.dfruits.security.impl.jdbc.JDBCUAAActivator.start(BundleContext) for how to provide a new jdbc connection and how to create a IUAAService
- run the /com.dfruits.security.impl.jdbc/schema/derby/db-structure.sql sql script (I used DTP for this)
- run the test suite com.dfruits.security.tests.UAATestSuite

Next time I will provide some screenshots of an existing RCP that makes use of the UAA services.

Comment 5 Erdal Karaca 2010-11-05 04:47:11 EDT

Created attachment 182457 [details]
Exemplary UI for the user management part of the UAA services

This is an exemplary UI that can be though of how an RCP could provide the user management part of the UAA services (authorisation/authentication are handled at appropriate places in the application, screenshots may follow).

On the screenshot there are three main columns: Permissions, Roles, Users.

Permissions:
- Unregistered Permissions
  -> these are permissions not known to the UAA services,
     i.e. generated by the application
- Registered Permissions
  -> permissions known to the UAA services
The exemplary UI populates the list of available permissions by implementing various "Permissions Registrars" (see interface IPermissionsRegistrar). E.g. a permissions registrar can provide
- all views (3.x) or named parts (4.x) to be opened
- commands to be executed
- editors to be opened
- wizards
- etc.

Roles:
- the various roles an application or the business logic can define
- registered permissions can be assigned to a role

Users:
- Principal + Subject

Comment 6 Oleg Besedin 2010-11-16 17:07:31 EST

(In reply to comment #0)
> I have recently started to adapt a 'new' concept for user management,
> authentication and authorization (UAA).

How about JAAS (Java Authentication and Authorization Service)? It seems that many of those concepts already present in Java (although it is quite possible to argue about their usability):

JAAS				The proposed contribution
java.security.Principal 	com.dfruits.security.authentication.Principal
java.security.Permission	com.dfruits.security.authorization.Permission
etc.

The good point about JAAS is that it ties into actual enforcement of permissions by JVM. The proposed contribution, from what I see, only provides interfaces / classes for the 'new' concepts and a way to store them in an SQL database. 

(By the way, the contribution contains about 30 new API classes / interfaces and no Javadoc as to what they are or how they are expected to be used.)

The interesting part would be to see definition of permissions useful in Eclipse universe and the way to enforce those permissions. 

I guess that you expect that safeguards for user information will come from the database side and that application-level security will be enforced by providing a closed system where a user, say, can't type a in a few lines of Java code in to get elevated access. That is one possibility, but even then I would be curious to know why wouldn't you base your solution on existing (and relatively well known) JAAS concepts. 

> It is based on and inspired by existing specifications from the ORCHESTRA
> project [1]:

Documents on the Orchestra's site have some licenses attached to them (such as "Open Geospatial Consortium, Inc. License Agreement"). That makes it complicated for people like myself: before I can click "accept" to be able to read the spec, it has to be approved by company's legal department, which, to put it mildly, would take some time and effort.

We do want/need better security mechanisms in Eclipse. However, this has to start from answering the "hard" questions:
- how permissions are going to be defined and regulated;
- how permissions are going to be enforced.

JAAS provides the only practical foundation to approach those questions for Java apps that I am aware of.  Previous attempts to use it in Eclipse were trumped by the amount of effort required to work with its fine-grane permissions. (We are speaking here about both initial investment and ongoing maintenance of permissions as code base changes.) The logical next step would be in creating some way to organize and maintain JAAS permissions into higher-level permissions, possibly Eclipse-centric, and tooling around them. However, that's just my take on it.

Comment 7 Erdal Karaca 2010-11-16 18:56:08 EST

> How about JAAS (Java Authentication and Authorization Service)? It seems that
> many of those concepts already present in Java (although it is quite possible
> to argue about their usability):

AFAIK, JAAS needs a secured middle tier, i.e. it is not to be used on client side where the user has full access to the permissions he can change (to his needs) by modifying properties files.

> 
> JAAS                The proposed contribution
> java.security.Principal     com.dfruits.security.authentication.Principal
> java.security.Permission    com.dfruits.security.authorization.Permission
> etc.
> 
> The good point about JAAS is that it ties into actual enforcement of
> permissions by JVM. The proposed contribution, from what I see, only provides
> interfaces / classes for the 'new' concepts and a way to store them in an SQL
> database.

Storing permissions in a SQL database (instead of properties) is one way to go to persist and manage all the various permissions and permission types.
As many enterprise (RCP) applications do have SQL backends, I decided to provide a "reference implementation" which is based on a SQL backend.

Moreover, there is no reason for why not mediating to JAAS when JVM specific permissions checking is needed.

> 
> (By the way, the contribution contains about 30 new API classes / interfaces
> and no Javadoc as to what they are or how they are expected to be used.)

(Btw. I assumed you would press the "Accept" button of the appropriate Service Specs and download them to read the included PDFs for your own interest where each interface and each method is described in detail...)

> The interesting part would be to see definition of permissions useful in
> Eclipse universe and the way to enforce those permissions.

I have added the term "permissions registrar", where a "registrar" provides the various permissions available in the eclipse universe (parts, wizards, commands, ui controls, ...).

> 
> I guess that you expect that safeguards for user information will come from the
> database side and that application-level security will be enforced by providing
> a closed system where a user, say, can't type a in a few lines of Java code in
> to get elevated access. That is one possibility, but even then I would be
> curious to know why wouldn't you base your solution on existing (and relatively
> well known) JAAS concepts. 

The equinox project has an encrypted password/data store. This is to be reused to encrypt/decrypt user information. Though, the adopter can provide his own ways to make sure those data are securely accessible.

Now, providing application-level security in the brave new world of eclipse (e4) is going to be much more complicated, IMHO. Imagine the UAA services are just injected into an eclipse context (I mean IEclipseContext). It will be very easy to replace the application UAA services by custom services by just binding new instances into the appropriate eclipse context, whether by direct execution of java code or by invoking some kind of scripting...
So, this is of course a yet-to-be-discussed topic.

> 
> > It is based on and inspired by existing specifications from the ORCHESTRA
> > project [1]:
> 
> Documents on the Orchestra's site have some licenses attached to them (such as
> "Open Geospatial Consortium, Inc. License Agreement"). That makes it
> complicated for people like myself: before I can click "accept" to be able to
> read the spec, it has to be approved by company's legal department, which, to
> put it mildly, would take some time and effort.

You are right, I should have insured that those licence agreement would comply with the EPL... I will be contacting the OGC to make sure whether I am on the right track or not... Though, on the first glance, it seemed to be OK. Of course, I am not a lawyer :-)

> 
> We do want/need better security mechanisms in Eclipse. However, this has to
> start from answering the "hard" questions:
> - how permissions are going to be defined and regulated;
> - how permissions are going to be enforced.

I think having something like the "permissions registrars" would answer the first question.

> 
> JAAS provides the only practical foundation to approach those questions for
> Java apps that I am aware of.  Previous attempts to use it in Eclipse were
> trumped by the amount of effort required to work with its fine-grane
> permissions. (We are speaking here about both initial investment and ongoing
> maintenance of permissions as code base changes.) The logical next step would
> be in creating some way to organize and maintain JAAS permissions into
> higher-level permissions, possibly Eclipse-centric, and tooling around them.
> However, that's just my take on it.

Defining eclipse-centric JAAS permissions will be no problem, IMO.
Some more questions: What permissions does an eclipse RCP need? Does it need to check whether the user has acces to specific views/editors/wizards/commands/...?
How are those permissions going to be maintained? Creating properties files which have to be deployed with the application? Or a central SQL database or the enterprise's LDAP server, or ...?

Comment 8 Erdal Karaca 2010-11-17 11:35:05 EST

Today, I spoke to two representatives of the OGC.
They told me there is nothing that prevents one to adapt OGC standards and re- distribute under any other licence.
Indeed, other open source communities have implemented specific standards and released their implementation under GPL, just to mention an example.
This is comparable to the OSGi alliance: The equinox project adapted the OSGi specs to release their implementation under EPL...
Hope that helps to clarify the IP issues...

Comment 9 Oleg Besedin 2010-11-17 16:29:53 EST

(In reply to comment #8)
> Today, I spoke to two representatives of the OGC.
> They told me there is nothing that prevents one to adapt OGC standards and re-
> distribute under any other licence.
> Indeed, other open source communities have implemented specific standards and
> released their implementation under GPL, just to mention an example.
> This is comparable to the OSGi alliance: The equinox project adapted the OSGi
> specs to release their implementation under EPL...
> Hope that helps to clarify the IP issues...

On the legal side - just to clarify things a bit:

- The pieces of OSGi that we re-release are licensed under Apache 2.0 (see  about.html file from the org.eclipse.osgi bundle and copyright headers on files such as AdminPermission);

- The APIs we provide should come with enough Javadocs to make them useful without referring to external documentation. In this case the need to refer to external documentation is aggravated by that documentation asking developers to agree to a custom license. The license might be fine (I honestly have no idea), but it will have to be first approved by the Eclipse Foundation and, for the scope of this contribution, I do not feel that the amount of work involved is justified. See http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf for some more details. 
This could be an interesting debate, but, in practical terms, unless document authors are willing to release it under one of the licenses on the approved list, we won't be able to use it. So the Javadoc + documentation submitted with new bundles will have to be self-sufficient.

- The Apache common library commons-dbutils that you included with the com.dfruits.security.impl.jdbc is licensed by Apache and can not be placed there. It has to be approved by the Eclipse Foundation to: a) to include it in the Orbit repository; and b) to use it in the new code.

- We do not speak about GPL :-).

Comment 10 Erdal Karaca 2010-11-18 01:06:17 EST

> On the legal side - just to clarify things a bit:
> - The pieces of OSGi that we re-release are licensed under Apache 2.0 (see 
> about.html file from the org.eclipse.osgi bundle and copyright headers on files
> such as AdminPermission);

My point is: There is a Provider who provides abstract specs and there is an Adopter A who can release his implementation under any license.
It does not matter if the license is Apache 2.0, GPL, EPL, etc.

> - The APIs we provide should come with enough Javadocs to make them useful
> without referring to external documentation. In this case the need to refer to
> external documentation is aggravated by that documentation asking developers to
> agree to a custom license. The license might be fine (I honestly have no idea),
> but it will have to be first approved by the Eclipse Foundation and, for the
> scope of this contribution, I do not feel that the amount of work involved is
> justified. See http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf for
> some more details. 

Javadocs is the minimum that should be provided as docs. As such, the current version was not meant to be final... It was just easier to refer to existing docs :-)

> This could be an interesting debate, but, in practical terms, unless document
> authors are willing to release it under one of the licenses on the approved
> list, we won't be able to use it. So the Javadoc + documentation submitted with
> new bundles will have to be self-sufficient.

As I said, this is not the final version...

> - The Apache common library commons-dbutils that you included with the
> com.dfruits.security.impl.jdbc is licensed by Apache and can not be placed
> there. It has to be approved by the Eclipse Foundation to: a) to include it in
> the Orbit repository; and b) to use it in the new code.

This is a very nice library to work with JDBC. I can try to refactor and use plain old JDBC API, but this will not make the code better...

> - We do not speak about GPL :-).

Oh, I am sorry, just forget about it :-)

---

So, what is the conclusion?

What we have at the moment:

- JAAS for JEE
- adapt UAA services specs from the OGC
- ... any other custom solutions go here ...

Comment 11 Oleg Besedin 2010-11-18 09:58:54 EST

(In reply to comment #10)
> So, what is the conclusion?

We had a quick discussion yesterday between Paul, Boris and me on where we would like to end of in the security dimension in e4. 

- We'd like to have concepts of roles and, [authenticated] users, and, possibly, permissions to be available at the UI level. We'd like to see them present in e4 UI models and used by the rendering code to figure out if a particular UI element shows up.

- We'd like to get UI pieces that provide front ends for logins / logouts / switch roles. 

- Whatever constructs we end up with describing roles / users / permission / login lifecycle, they have to map to JAAS for Java world and be useful in Javascript world.

- We do not feel that we can provide "hard" security with the resources we have. What this means, is that security model will assume that users can't alter RCP apps or underlying OS elements. In a sense, our security model will be the extension of "capabilities" from 3.x world. It might be better to market this work as "capabilities" rather then "security" to avoid confusion.

- While we may need to provide an example of how users / roles / permissions can be managed using some back end, this should not be the focus at this time for this team; that would be a "helpwanted" item where we hope to see other people contribute.

- In particular, the strict enforcement of restriction (in a SecurityManager sence) will be out of scope of this work. However, we'd like to do our work in a manner that the gap between UI roles and JAAS roles can be filled later.

Now, the question is, who is going to do it :-). Erdal, if you are interested, I can start by creating an umbrella bug and several more detailed bugs for the elements above.

Comment 12 Erdal Karaca 2010-11-18 14:04:15 EST

(In reply to comment #11)
> (In reply to comment #10)
> > So, what is the conclusion?
> 
> We had a quick discussion yesterday between Paul, Boris and me on where we
> would like to end of in the security dimension in e4. 
> 
> - We'd like to have concepts of roles and, [authenticated] users, and,
> possibly, permissions to be available at the UI level. We'd like to see them
> present in e4 UI models and used by the rendering code to figure out if a
> particular UI element shows up.
> 

So, that means there will be no authentication routines inside e4?
I.e. if user U is "logged in" (maybe some single-sign-on mechanisms that rely on JAAS), then, all the app has to do is to ask what role U has and determine what permissions are available, i.e. what UI elements may be accessible by that role...

> - We'd like to get UI pieces that provide front ends for logins / logouts /
> switch roles. 
> 

Is a login supposed to be done at startup (splash handler)? Or is this supposed to be done whenever the UI needs to check what UI elements should be visible/active/...?
What should happen once the user presses the "logout button"?

> - Whatever constructs we end up with describing roles / users / permission /
> login lifecycle, they have to map to JAAS for Java world and be useful in
> Javascript world.
> 

> - We do not feel that we can provide "hard" security with the resources we
> have. What this means, is that security model will assume that users can't
> alter RCP apps or underlying OS elements. In a sense, our security model will
> be the extension of "capabilities" from 3.x world. It might be better to market
> this work as "capabilities" rather then "security" to avoid confusion.
> 

Yes, this is a very important distinction.

> - While we may need to provide an example of how users / roles / permissions
> can be managed using some back end, this should not be the focus at this time
> for this team; that would be a "helpwanted" item where we hope to see other
> people contribute.

OK...

> - In particular, the strict enforcement of restriction (in a SecurityManager
> sence) will be out of scope of this work. However, we'd like to do our work in
> a manner that the gap between UI roles and JAAS roles can be filled later.

> Now, the question is, who is going to do it :-). Erdal, if you are interested,
> I can start by creating an umbrella bug and several more detailed bugs for the
> elements above.

Yes, please provide detailed descriptions of the requirements.

Comment 13 Oleg Besedin 2010-11-19 10:57:34 EST

(In reply to comment #12)
> Yes, please provide detailed descriptions of the requirements.

I've opened / updated:
bug 330671 Support for user authentication
bug 330675 Provide capabilities-like mechanism based on the authenticated user
bug 328277 handle @Authorize annotation in injection engine 

I'll mark this bug as a duplicate of the bug 330671.

*** This bug has been marked as a duplicate of bug 330671 ***