What is the prefferd way to install Crossbar?

[Алексей Баранов]

Hello!

As I read few monthes ago installation from ubuntu packages was the preffered way. But now it seems that repository is not updated to latest version. 

So what is the preffered way to install Crossbar at tnis moment and near future?

Thanks/

[Sergey Korolev]

Hi,

Just for detailed info.

I've tried to update from apt installed 0.13.2 to 17.3.1 by pypy, but without luck.

I've attached all steps.

Any advice?

[Alexander Gödde]

Hi!

There are currently two recommended ways of installing Crossbar.io (since there are currently no up-to-date packages):

* using Docker

* installing into a virtualenv (to prevent Cossbar.io dependencies from interfering with the system Python)

@Sergey: It's probably easier to just copy your configuration file and then use this with a new, up-to-date installation instead of trying to upgrade.

Regards,

Alex

[Steve Waterbury]

Hi Tobias,

We are planning to use crossbar in a NASA enterprise
application, and this will require the use of Kerberos
authentication (Active Directory / GSSAPI).

We are looking into using the python-gssapi package:
https://github.com/pythongssapi/python-gssapi
It appears to be at least a starting point.

Creating a server-side authenticator that uses one of
the existing crossbar authentication interfaces will
probably be non-trivial -- I'm guessing the crossbar
"ticket-based" auth mechanism would be the closest
fit.

Has anyone done any work in this area?

Thanks,
Steve

[Steve Waterbury]

[Tobias Oberstein]

Hi Steve,

nice to hear again,

Am 17.04.2017 um 17:42 schrieb Steve Waterbury:
> Hi Tobias,
>
> We are planning to use crossbar in a NASA enterprise

Awesome! I figure your pitching did work;) Very cool.

> application, and this will require the use of Kerberos
> authentication (Active Directory / GSSAPI).

Ah, I see. This might be fun to make it fly. I've read into it a little
right now - comments down below.

But anyway, whatever it takes (and it won't be rocket science -pun;), we
will add any bits needed to allow this. NASA is a magical word in my ears;)

>
> We are looking into using the python-gssapi package:
> https://github.com/pythongssapi/python-gssapi
> It appears to be at least a starting point.
>
> Creating a server-side authenticator that uses one of
> the existing crossbar authentication interfaces will
> probably be non-trivial -- I'm guessing the crossbar
> "ticket-based" auth mechanism would be the closest
> fit.

It is close, but the problem is: the dynamic authenticator stuff in
Crossbar.io runs _after_ the initial HTTP WebSocket Upgrade handshake.
But we need to hook into the HTTP handshake already for Kerberos/AD
auth. See below ..

>
> Has anyone done any work in this area?
>
> Thanks,
> Steve
>

Let me catch up with the goals / full picture.

So the goal is to have browsers (on an Intranet) connect to Crossbar.io
with AutobahnJS and authenticate against AD?

MS Edge, Chrome, Firefox?

If so, and if I do get that right (I've skimmed into the links down
below), that runs under the term

"HTTP Negotiate" based HTTP authentication, and it works like:

1)
Browser sends:

GET /ws HTTP/1.1
Upgrade: WebSocket

2)
Server answers:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Negotiate

Browser now talks to AD/KDC (possibly via GSSAPI) and gets a magic
ticket, and then

3)
does a new request (the garbage is the ticket from AD/KDC):

GET /ws HTTP/1.1
Upgrade: WebSocket
Authorization: Negotiate a87421000492aa874209af8bc028

Now server checks the ticket, and the ticket (if valid) will also
provide user creds (like WAMP realm / authid / authrole).

This checking is not talking over the network, but only uses the local
server Kerberos secret (like the file pointed to by KRB5_KTNAME).

And this checking can be done over GSSAPI, at which point the question
of Python library arises (python-gssapi).

---

The problem is: all dynamic authenticators invocations in Crossbar.io do
actually get all the HTTP headers sent by the client.

This includes the Authorization header in 3).

So actually, if the browser would already start with 3), WAMP-Anonymous
could be used with a dynamic authenticator:

https://github.com/crossbario/crossbar-examples/tree/master/authentication/anonymous/dynamic

The authenticator would extract the HTTP Authorization header from the
"details" argument provided to the dynamic authenticator procedure.

It could then do its check thing (using GSSAPI), and return
realm/authid/authrole - or deny.

However, there is currently no way of making 2) happen upon 1).

Well, it's possible in Autobahn, but nothing exposes it in Crossbar.io
currently.

Am I on the right track with all this?

Cheers,
/Tobias

links I skimmed:

http://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos
http://manpages.ubuntu.com/manpages/xenial/man8/negotiate_kerberos_auth.8.html
https://github.com/alexeyzotov/authkerb
https://pypi.python.org/pypi/kerberos
https://msdn.microsoft.com/en-us/library/ms995330.aspx
https://www.isode.com/whitepapers/kerberos.html
https://kaazing.com/doc/5.0/security/c_authentication_kerberos/
https://www.ibm.com/support/knowledgecenter/ssw_i5_54/apis/gss_accept_sec_context.htm

[Steve Waterbury]

Hi Tobias,

Thanks very much for your quick response!
Comments below ...

On 04/17/2017 04:47 PM, Tobias Oberstein wrote:
> Hi Steve,
>
> nice to hear again,
>
> Am 17.04.2017 um 17:42 schrieb Steve Waterbury:
>> Hi Tobias,
>>
>> We are planning to use crossbar in a NASA enterprise
>
> Awesome! I figure your pitching did work;) Very cool.

So far, at least! Now I have to show that it can
actually work ... ;)

>> application, and this will require the use of Kerberos
>> authentication (Active Directory / GSSAPI).
>
> Ah, I see. This might be fun to make it fly. I've read into it a little
> right now - comments down below.
>
> But anyway, whatever it takes (and it won't be rocket science -pun;), we
> will add any bits needed to allow this. NASA is a magical word in my ears;)

Great! ;) Also, I plan to make the core of my app open
source, once I have gone through all the NASA hoops to
release it, so hopefully it will be more than just a
nice-sounding thing ... maybe something actually useful
to others! :)

>>
>> We are looking into using the python-gssapi package:
>> https://github.com/pythongssapi/python-gssapi
>> It appears to be at least a starting point.
>>
>> Creating a server-side authenticator that uses one of
>> the existing crossbar authentication interfaces will
>> probably be non-trivial -- I'm guessing the crossbar
>> "ticket-based" auth mechanism would be the closest
>> fit.
>
> It is close, but the problem is: the dynamic authenticator stuff in
> Crossbar.io runs _after_ the initial HTTP WebSocket Upgrade handshake.
> But we need to hook into the HTTP handshake already for Kerberos/AD
> auth. See below ..
>
>>
>> Has anyone done any work in this area?
>>
>> Thanks,
>> Steve
>>
>
> Let me catch up with the goals / full picture.
>
> So the goal is to have browsers (on an Intranet) connect to Crossbar.io
> with AutobahnJS and authenticate against AD?
>
> MS Edge, Chrome, Firefox?

Actually, our app is not browser-based but rather a desktop GUI
app that we are creating using PyQt5 and Autobahn-Python's
twisted API (plus qt5reactor). My programming team (and myself)
do not like javascript -- we want to do everything in Python. ;)

We already have a version of our app that can authenticate to
crossbar over the "ticket-based authentication" (based on that
crossbar example code) and do rpc and pub/sub.

What you describe below for the protocol sounds correct as far
as I understand Kerberos/SPNEGO -- but just substitute "GUI client"
everywhere you have "browser".

Once Crossbar support Kerberos authentication, I am sure
there will be lots of organizations that will want to
use it for browser applications, and it should work the same.

[I only have a few more comments below ...]

I have used AD/Kerberos auth in web applications with
Apache/mod_auth_kerb but have never gotten into the guts of it
as will be needed for this implementation. As far as I
understand the protocol, you seem to be on the right track.

My team will be working on the Autobahn-Python client side, and
as you imply above, Autobahn might already expose enough for
us to implement the hooks in the client -- probably using
python-gssapi or something similar.

Again, I really appreciate your interest and willingness to look
into this! I think it can potentially enable a large domain
of internal enterprise applications of Crossbar and Autobahn,
and possibly bring you some customers. ;)

Steve

[Adam Jorgensen]

Correct me if I'm wrong, but if you are writing a desktop app then that app could use python-gssapi directly in the application in order to obtain what it needs authenticate

against Crossbar?

[Steve Waterbury]

I think that is correct ... what remains is for crossbar to do
the server-side interaction with the Kerberos domain controller
(which is how the client's credential [ticket] is validated).

> <http://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos>
> >
> http://manpages.ubuntu.com/manpages/xenial/man8/negotiate_kerberos_auth.8.html
> <http://manpages.ubuntu.com/manpages/xenial/man8/negotiate_kerberos_auth.8.html>
>
> >
> > https://github.com/alexeyzotov/authkerb
> <https://github.com/alexeyzotov/authkerb>
> > https://pypi.python.org/pypi/kerberos
> <https://pypi.python.org/pypi/kerberos>
> > https://msdn.microsoft.com/en-us/library/ms995330.aspx
> <https://msdn.microsoft.com/en-us/library/ms995330.aspx>
> > https://www.isode.com/whitepapers/kerberos.html
> <https://www.isode.com/whitepapers/kerberos.html>
> > https://kaazing.com/doc/5.0/security/c_authentication_kerberos/
> <https://kaazing.com/doc/5.0/security/c_authentication_kerberos/>
> >
> https://www.ibm.com/support/knowledgecenter/ssw_i5_54/apis/gss_accept_sec_context.htm
> <https://www.ibm.com/support/knowledgecenter/ssw_i5_54/apis/gss_accept_sec_context.htm>
>
> >
> >
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "Crossbar" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to crossbario+...@googlegroups.com
> <mailto:crossbario+...@googlegroups.com>.
> To post to this group, send email to cross...@googlegroups.com
> <mailto:cross...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/crossbario/e6276a34-7fee-4034-9679-ddec644d46df%40googlegroups.com
> <https://groups.google.com/d/msgid/crossbario/e6276a34-7fee-4034-9679-ddec644d46df%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Tobias Oberstein]

Hi Steve,

>> But anyway, whatever it takes (and it won't be rocket science -pun;), we
>> will add any bits needed to allow this. NASA is a magical word in my
>> ears;)
>
> Great! ;) Also, I plan to make the core of my app open
> source, once I have gone through all the NASA hoops to
> release it, so hopefully it will be more than just a
> nice-sounding thing ... maybe something actually useful
> to others! :)

Sounds good!

The "model driven software development" (MDS .. roughly) perspective,
and how WAMP could take a role there, is very interesting for a number
of reasons. I had discussions with guys from big corps that a much into
the MDS, and like to start creating systems from formally defining WAMP
interfaces, and then components, etc.

Maybe this isn't exactly what you are working on, but it seems related
.. please keep me updated on your efforts.

> Actually, our app is not browser-based but rather a desktop GUI
> app that we are creating using PyQt5 and Autobahn-Python's
> twisted API (plus qt5reactor). My programming team (and myself)

Ahh. I see. PyQt is really nice, yes. Qt is nice, but it comes with the
C++ baggage which is mostly "no gain, but pain" for desktop apps these
days. But using Qt from Python to the rescue;)

FWIW, as a correlate, there is also a thing called Kivy with a slightly
different focus, but also nice

https://kivy.org/

Works with Autobahn and Crossbar.io (they have Twisted integration):

https://github.com/crossbario/crossbar-examples/tree/master/kivy

> do not like javascript -- we want to do everything in Python. ;)

=)

It is so sad that Brendan Eich only had like 10 days to come up a
scripting lang for browsers, and didn't consider Python. We all would be
living in a better world now. Anyways. Lost cause.

Personally, I want to get into Typescript more to get around the defects
of JS. Well, if I find time.

>
> We already have a version of our app that can authenticate to
> crossbar over the "ticket-based authentication" (based on that
> crossbar example code) and do rpc and pub/sub.
>
> What you describe below for the protocol sounds correct as far
> as I understand Kerberos/SPNEGO -- but just substitute "GUI client"
> everywhere you have "browser".

Ok, this simplifies things. Because it doesn't need to piggyback on the
initial HTTP handshake.

I think it can be done today, in AB and CB, with WAMP-Ticket and dynamic
authenticators.

Your Python desktop app opens a connection to Crossbar.io (CB). This can
be WebSocket or RawSocket. Doesn't matter, because the Kerberos thing is
hooked on top of the WAMP authentication message exchange (not the HTTP
handshake as would be needed for browsers).

The app starts joining, announcing WAMP-Ticket as the only authmethod it
is willing to do:

HELLO message from app -> CB

Crossbar.io will check if it was configured for WAMP-Ticket, and if so,
answer that with a CHALLENGE message CB -> app.

Sidenote: if you need to provide additional challenge info at this
point, we can do that, but it needs some new code.

The app will use GSSAPI to talk to Kerberos and construct a Kerberos
"Service Ticket" for the target CB/realm.

The app will then answer the CHALLENGE message with AUTHENTICATE,
providing the above "Service Ticket".

CB will invoke your dynamic authenticator, and this can check the
provided Service Ticket locally then (again via GSSAPI).

---

Unless I have overlooked sth, above should work today in AB/CB.

I'd watch out for 2 things:

a) blocking stuff in python-gssapi: if this lib is blocking, probably
deferToThread the respective blocking calls

b) AUTHENTICATE.Signature

https://github.com/crossbario/autobahn-python/blob/master/autobahn/wamp/message.py#L1003

is where the Kereberos Service Ticket will be transmitted.

And since this field wants a string type (not bytes), you probably will
have to encode the Kerberos ticket with base64 or something. No big
deal, and not performance relevant.

>
> Once Crossbar support Kerberos authentication, I am sure
> there will be lots of organizations that will want to
> use it for browser applications, and it should work the same.

I agree with that. It is one piece in the puzzle that will make it
easier for big coprs/orgs to use CB.

I have created an issue

https://github.com/crossbario/crossbar/issues/1045

> Again, I really appreciate your interest and willingness to look
> into this! I think it can potentially enable a large domain
> of internal enterprise applications of Crossbar and Autobahn,
> and possibly bring you some customers. ;)

Absolutely;)

Cheers,
/Tobias