> On 2 mrt. 2016, at 13:39, Christian Schneider <ch...@die-schneider.net> wrote:
> I think JAAS is very suitable for this.
> For example we did a POC for a customer some time ago that did the following:
> 1. The user authenticates on the client using JAAS (In this case kerberos
> single sign on). So on the client the roles are already available to for
> example grey out buttons.
Don’t understand, how can you translate e.g. the FilePermission class to
something Javascript could understand? Especially since the Java Permission are
defined to be completely procedural. In theory, a permission can be denied only
during full moon. This was the biggest of many mistakes mr. Gong made when
designing Java security in 1.2. Because of the unpredictability, you cannot
cache the result of the security check and you cannot distribute it; it always
requires a (remote) call.
I can hardly blame Li because I was also convinced that objects were the best
thing since slight bread in 1998. The idea of abstracting the decision behind a
facade made a lot of sense. Now almost 20 years later it has become abundantly
clear that there are also many drawbacks to this model, especially in
distributed environments. And you’re building a distributed system today, even
if you think you don’t.
> 2. The client communicates with the server using the JAAS authentication. On
> the transport layer SPNEGO transported the challenge response communication
> for kerberos.
So each security requests in Javascript is a REST call? Isn’t that awkward and
expensive? In a project I did we had lots of GUI decisions based on the
permissions of the user?
> 3. The server establishes a JAAS login using the credentials above. So after
> the login the server also knows the roles and can authorize access
> accordingly.
> So this allows an end to end single sign on using standardized authentication.
> So while I think OSGi can also standardize this I see the risk that an OSGi
> spec is then only applicable to OSGi while JAAS is also available in standard
> Java as well as Java EE.
I think in many cases we can leverage the OSGi infrastructure and learn from
the mistakes Java made (permission being objects and not declarative, and the
awkward API). I think Java is held back in too many cases by trying to stick to
18+ year old standards that today have solutions that are much more applicable
in a distributed world. We found that with the Authority API in OSGi enRoute we
could easily leverage the implementations of LoginModules while the user code
stays very light and simple and not polluted with the often bad API design in
classic Java. And in OSGi, a clean service API is worth its weight in gold.
> One thing that should be standardized though even in the JAAS case is how to
> distinguish users and roles in a JAAS login. Currently this is implementation
> specific which makes using JAAS harder than it needs to be.
Java has a history of not really consistently grasping the difference between
roles, users, groups, permissions, and actions …
> In any case what I learned from the efforts is that when you want to
> standardize authentication you have to also support more than simple
> username/password and also take into account
> advanced authentications like kerberos, SPNEGO, oauth, STS. I am not sure if
> all of these can be implemented using JAAS but it provides some flexibility
> so it might work.
Of course, the problem is that you should NOT make this in any way visible to
the normal service implementation code. This is an implementation detail behind
a good service facade. We’ve use the Login Modules to interface with LDAP and I
cannot see why other implementations could not be used as well. I personally
used Persona from Mozilla in this model. The trick is to leverage
implementations but not pollute the service API with irrelevant issues.
If you’re interested, there are two RFPs in flight at the OSGi Alliance: An
[Authorization][1] and an [Authentication][2].
Kind regards,
Peter Kriens
[1]: https://github.com/osgi/design/blob/master/rfps/rfp-0165-Authorization.pdf
[2]: https://github.com/osgi/design/blob/master/rfps/rfp-0164-Authentication.pdf
>
> Christian
>
> On 02.03.2016 10:37, Peter Kriens wrote:
>> In the upcoming transaction composition spec we’re discussing setting a
>> standard for this piece of code that receives the external request. The
>> Coordinator will likely play a role. In OSGi enRoute, we mandated that the
>> Authority service should be set, which is also thread based. Java security
>> was not possible because we needed to transfer the permission info to the
>> external GUI code. (We still verify it on the server of course, but I think
>> it sucks when you press a button you’re not supposed to press.) The Java
>> security permission model hides this information by classes that cannot be
>> transferred to another system.
> It works for the kerberos approach above but it does not work out of the box
> for username/password. I am pretty sure it can be implemented though. You can
> put arbitrary information
> into the subject and you can read out the information at the point where you
> send the remote request out.
>
> --
> Christian Schneider
> http://www.liquid-reality.de <http://www.liquid-reality.de/>
>
> Open Source Architect
> http://www.talend.com <http://www.talend.com/>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
