Smalltalk › Pharo › Pharo Smalltalk Users

Enterprise authentication with Kerberos (was Re: Smalltalk Argument)

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 2 messages Options
Ben Coman
Reply | Threaded
Open this post in threaded view
♦
♦
|

Enterprise authentication with Kerberos (was Re: Smalltalk Argument)

Ben Coman
Kerberos deserves its own topic rather than mixing in with the Smalltalk Argument one that now stands at 53 posts.
Hopefully I've managed to extract pertinent parts of this thread.  

On Thu, Oct 26, 2017 at 3:14 PM, [hidden email] <[hidden email]> wrote:
Sure. Current main issue is to have Pharo work with Kerberos as secured Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole of crypto things. 

How would you see ParrotTalk work? 

I made a XmppTalk thing (binding for libstrophe) for having Pharo images and other stuff talk together (currently using OpenFire/Gajim/Profanity) FWIW


libstrophe does the SSL thing under the hood (using OpenSSL) and is actively maintained.

And I currently work with Kafka so, Pharo as a consumer or producer, sure am interested. But need Kerberos support.

Tell me more about your vision. Even better, draw it in some way :-)

Phil


On Thu, Oct 26, 2017 at 8:52 PM, henry <[hidden email]> wrote:
Perhaps not, or not yet. Perhaps it is the communications foundation for an always-on cloud/bigData control layer.

I would position ParrotTalk as a Kerberos transport. ParrotTalk does 2048-bin key negotiation and subsequent encryption/encoding, both user-supplied. 

Please see the attached diagram, co-locating ParrotTalk with my other components.

ParrotTalk does not do user authentication/authorization. Which means to me that I should consider Kerberos authorization/authentication to establish as an integratable transport to play in bigData.

This means you still need a Kerberos client and I need a Kerberos client. How do we start?

- HH

PS: I did much work integrating Kafka into a framework. I was thinking of inserting msg sending replication to a partition count of replicate queues for sending and receiving Hubbub traffic, thus inserting right where Kerberos is in the diagram. I would love to see client coupling for Kerberos, Kafka and Hadoop, while I figure out proper security to make that group happy with this as a possible control layer solution, forking off jobs.


On Thu, Oct 26, 2017 at 9:15 PM, henry <[hidden email]> wrote:
I think another good service to integrate well to is Elastic Search.

Of the 4 types of integration, I vote for and step forward to volunteer to help Kerberos integration in Pharo. What to do? 



On Thu, Oct 26, 2017 at 10:38 PM, henry <[hidden email]> wrote:
A Kerberos effort will have to be a group effort. Sideways to my main focus and your all’s main focii.

 
On Thu, Oct 26, 2017 at 11:39 PM, Paulo R. Dellani <[hidden email]> wrote:
This all sounds very interesting. What is the idea? Wrap libkrb5 through UFFI or implement it in Smalltalk? 


On Fri, Oct 27, 2017 at 6:06 AM, [hidden email] <[hidden email]> wrote:
There are two key Kerberos implementations one can use with Hadoop.

One is the FreeIpa/RedHat IdM.
The other is ActiveDirectory.

I am using FreeIPA which bundles MIT Kerberos/389/sssd and more for making a CA etc. Works wonderfullý well.

AD is well ... part of the corporate landdscape.

Most of Kerberos needs are done with Java in Hadoop. But details are buried in private Sun classes..

Google Madness beyond the gate hadoop for some Lovecraftian quotes describing the situation along educated info.

Phil

On Thu, Oct 26, 2017 at 6:23 PM, henry <[hidden email]> wrote:
I have no idea which is best. For being able to say we use industry standard Kerberos, calling an accepted implementation seems wise, like OpenSSL support.
 
 
On Sat, Oct 28, 2017 at 4:51 AM, henry <[hidden email]> wrote:
 How about Kerberos? Can we get a team to look closely at bringing integration for enterprise users? That would be helpful, or can you just put it behind a Kerberos wrapper? If that would work, collecting a demo, that could unlock more corporate wallets , for investment.

- HH
Ben Coman
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Enterprise authentication with Kerberos (was Re: Smalltalk Argument)

Ben Coman
> On Thu, Oct 26, 2017 at 3:14 PM, [hidden email] <[hidden email]> wrote:

>>
>> Sure. Current main issue is to have Pharo work with Kerberos as secured Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole of crypto things.
>
>
> On Thu, Oct 26, 2017 at 9:15 PM, henry <[hidden email]> wrote:
>>
>> Of the 4 types of integration, I vote for and step forward to volunteer to help Kerberos integration in Pharo. What to do?  
>  
>
> On Thu, Oct 26, 2017 at 11:39 PM, Paulo R. Dellani <[hidden email]> wrote:
>>
>> This all sounds very interesting. What is the idea? Wrap libkrb5 through UFFI or implement it in Smalltalk?
>
>
> On Fri, Oct 27, 2017 at 6:06 AM, [hidden email] <[hidden email]> wrote:
>>
>> There are two key Kerberos implementations one can use with Hadoop.
>> One is the FreeIpa/RedHat IdM.
>> The other is ActiveDirectory.
>>
>> I am using FreeIPA which bundles MIT Kerberos/389/sssd and more for making a CA etc. Works wonderfullý well.
>>
>> AD is well ... part of the corporate landdscape.
>>
>> Most of Kerberos needs are done with Java in Hadoop. But details are buried in private Sun classes..
>>
>>
>> On Thu, Oct 26, 2017 at 6:23 PM, henry <[hidden email]> wrote:
>>>
>>> I have no idea which is best. For being able to say we use industry standard Kerberos, calling an accepted implementation seems wise, like OpenSSL support.
>
>  
> On Sat, Oct 28, 2017 at 4:51 AM, henry <[hidden email]> wrote:
>>
>>  How about Kerberos? Can we get a team to look closely at bringing integration for enterprise users? That would be helpful, or can you just put it behind a Kerberos wrapper? If that would work, collecting a demo, that could unlock more corporate wallets , for investment.
>>
>>
I'm not very familiar with the domain, but maybe we should consider GSSAPI & SSPI.  "The dominant GSSAPI mechanism implementation in use is Kerberos. Unlike the GSSAPI, the Kerberos API has not been standardized and various existing implementations use incompatible APIs. The GSSAPI allows Kerberos implementations to be API compatible." [1]  "SSPI is a proprietary variant of GSSAPI with extensions and very Windows-specific data types" [2]

SSPI/Kerberos Interoperability with GSSAPI



cheers -ben
Free forum by Nabble Edit this page