[jboss-jira] [JBoss JIRA] (JGRP-1657) Kerberos based authentication

[Richard Achmatowicz (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977193#comment-12977193 ] 

Richard Achmatowicz edited comment on JGRP-1657 at 6/17/14 5:30 PM:
--------------------------------------------------------------------

I have been looking at this recently.  A couple of points:

1. Kerberos as an authentication mechanism does not seem to be a great fit with JGroups, in the sense that:
- Kerberos models authentication of clients against servers (providing services like ftp, telnet, email) in a distributed system, where the relationships between clients and servers doesn't change over time
- JGroups AUTH models authentication on joining member to coordinator, where the coordinator may change over time (and probably will) - in that sense, all clients are also potential coordinators

The client server nature of Kerberos is reflected in the setting up of Kerberos user principals for clients and and service principals for services which are used for the authentication. I'm not sure how this would map to a company's JGroups setup. Maybe one service principal, representing the group, used for all members?

2. The implementation is on the right track, in that they make use of GSSAPI (essentially a java to native Kerberos interface) to create a security context on the client, a security context on the server and then perform the challenge-response cycle between the two to perform the authentication. The credentials for the client and or the server are picked up by prompting the user in this case, but could be picked up without user intervention from a a local Kerberos ticket cache (initialised by kinit) or a local keytab file for the service. 

3. GSSAPI also provides features for encryption and integrity checking once the authentication has succeeded, but these are point-to-point based and so not suitable for use it a group situation, it seems to me. Instead, use ENCRYPT to perform encryption and integrity checking at the group level.

Authentication between the client security context and the server security context is formally done making use of a challenge-response cycle, as demonstrated in DemoToken. In the implementation provided, they assume that the GSSAPI Kerberos implementation is a single exchange, which isn't really safe if a different provider is used. Better to carry put the exchange.


 
   


was (Author: rachmato):
I have been looking at this recently.  A couple of points:

1. Kerberos as an authentication mechanism does not seem to be a great fit with JGroups, in the sense that:
- Kerberos models authentication of clients against servers (providing services like ftp, telnet, email) in a distributed system, where the relationships between clients and servers doesn't change over time
- JGroups AUTH models authentication on joining member to coordinator, where the coordinator may change over time (and probably will) - in that sense, all clients are also potential coordinators

The client server nature of Kerberos is reflected in the setting up of Kerberos user principals for clients and and service principals for services which are used for the authentication. I'm not sure how this would map to a company's JGroups setup. Maybe one service principal, representing the group, used for all members?

2. The implementation is on the right track, in that they make use of GSSAPI (essentially a java to native Kerberos interface) to create a security context on the client, a security context on the server and then perform the challenge-response cycle between the two to perform the authentication. The credentials for the client and or the server are picked up by prompting the user in this case, but could be picked up without user intervention from a a local Kerberos ticket cache (initialised by kinit) or a local keytab file for the service. 

3. GSSAPI also provides features for encryption and integrity checking, but these are point-to-point based and so not suitable for use it a group situation, it seems to me. Instead, use ENCRYPT to perform encryption and integrity checking at the group level.

Authentication between the client security context and the server security context is formally done making use of a challenge-response cycle, as demonstrated in DemoToken. In the implementation provided, they assume that the GSSAPI Kerberos implementation is a single exchange, which isn't really safe if a different provider is used. Better to carry put the exchange.


 
   

> Kerberos based authentication
> -----------------------------
>
>                 Key: JGRP-1657
>                 URL: https://issues.jboss.org/browse/JGRP-1657
>             Project: JGroups
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: jgroups-krb-poc.zip
>
>
> Martin Swales submitted a kerberos-based AUTH plugin (code attached). This needs to be integrated, and possibly back-ported to 3.x (3.3, 3.2 ?). 
> Tasks to be done include:
> - Change package name from com.redhat.x to org.jgroups.x
> - Replace commons-logging with JGroups' own logging mechanism
> - Replace sun.misc.Base64Encoder/Decoder with a version independent of sun.misc
> - Test case
> - Documentation



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)