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.
2. The client communicates with the server using the JAAS
authentication. On the transport layer SPNEGO transported the challenge
response communication for kerberos.
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.
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.
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.
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
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
