What is the prefferd way to install Crossbar?

#1

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/

0 Likes

#2

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?

Crossbar upgrade.pdf (42 KB)

···

On Monday, April 10, 2017 at 6:04:10 PM UTC+7, Алексей Баранов wrote:

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/

0 Likes

#3

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

···

Am Montag, 10. April 2017 15:56:22 UTC+2 schrieb 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?

On Monday, April 10, 2017 at 6:04:10 PM UTC+7, Алексей Баранов wrote:

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/

0 Likes

#4

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

0 Likes

#5

Hi Steve,

nice to hear again,

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).

···

Am 17.04.2017 um 17:42 schrieb Steve Waterbury:

---

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

0 Likes

#6

Hi Tobias,

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

Hi Steve,

nice to hear again,

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 ... :wink:

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! :wink: 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! :slight_smile:

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. :wink:

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 ...]

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?

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. :wink:

Steve

···

On 04/17/2017 04:47 PM, Tobias Oberstein wrote:

Am 17.04.2017 um 17:42 schrieb Steve Waterbury:

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

0 Likes

#7

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?

···

On Monday, 17 April 2017 23:39:17 UTC+2, Stephen Waterbury wrote:

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 … :wink:

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! :wink: 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! :slight_smile:

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. :wink:

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 …]

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:

Browser sends:

GET /ws HTTP/1.1

Upgrade: WebSocket

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

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?

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. :wink:

Steve

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

0 Likes

#8

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).

···

On 04/18/2017 12:52 AM, Adam Jorgensen wrote:

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?

On Monday, 17 April 2017 23:39:17 UTC+2, Stephen Waterbury wrote:

    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 ... :wink:

    >> 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! :wink: 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! :slight_smile:

    >>
    >> We are looking into using the python-gssapi package:
    >> https://github.com/pythongssapi/python-gssapi
    <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. :wink:

    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 ...]

    > 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
    <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?

    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. :wink:

    Steve

    > Cheers,
    > /Tobias
    >
    > links I skimmed:
    >
    > http://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos
    <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.

0 Likes

#9

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! :wink: 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! :slight_smile:

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. :wink:

=)

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. :wink:

Absolutely;)

Cheers,
/Tobias

0 Likes