Authenticating the Authenticator

#1

Is the only way to authenticate the connection by the component trying to register an authentication service by using static permissions? I am really trying to avoid having to hard-code accounts and passwords in a configuration file since this seems insecure. For most hosting environments you would probably make these environment variables so they can be configured through the management website as well.

0 Likes

#2

Hi Chris,

yep, a dynamic authenticator needs to authentiate itself too.

Is the only way to authenticate the connection by the component trying
to register an authentication service by using static permissions? I am

If you mean, is this

1. static WAMP-CRA (or WAMP-Ticket) with secrets literally contained in the node configuration file

the only way to authenticate a dynamic authenticator? Then, no, you can also have:

2. implement the authenticator in Python, run the component embedded in a Crossbar.io router worker and use a fixed authrole assignment (possible, since the embedded code is trusted/known anyway)

-> there is no issue since there is no secret anyway

3. use Unix domain sockets for connecting the authenticator to the router, use filesystem permissions for security, and a fixed WAMP authrole again

-> there is no issue since there is no secret anyway

···

Am 26.12.2015 um 11:02 schrieb Chris Beckett:

---

1. - 3. are possible today with Crossbar.io release, while the following options are upcoming.

---

4. static WAMP-TLS (TLS with WebSocket or RawSocket) for connecting the authenticator to the router and TLS client certificate authentication, and have the authid set from the cert, and the authrole from static config

-> there is no issue since the secret (the private key part) is not exposed to Crossbar.io at all

Support for WAMP-TLS is in trunk:

https://github.com/crossbario/crossbarexamples/tree/master/authenticate/tlsdynamic

But: https://github.com/crossbario/crossbar/issues/569

5. static WAMP-CRA with secrets from env vars

I agree (to what I guess you hint at) that it would make sense to be able to use static WAMP-CRA authentication with secrets coming from environment variables, instead of literal values in the node configuration:

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

(We have such option for listening TCP ports already ..)

-> the issue is moved elsewhere (the secret needs to be on the box where Crossbar.io, but is set outside the node config).

6. static WAMP-cryptosign

Then I am working on WAMP-cryptosign, which is a new WAMP-level authentication scheme based on Curve25519 crypto.

This will run over any WAMP transport, including non-TLS ones.

With WAMP-cryptosign, a node's static authentication configuration will have entries for client public keys:

"principals": {
     "backend-inst01": {
        "pubkey": "rxVbS2hlekZOZVMlPjKwknj4LzHEiKxTpKQEjodJhAE=",
        "role": "backend-component"
     }
}

-> there is no issue since the secret (the private key part) is not exposed to Crossbar.io at all

===

I think with 1. - 6. above, most scenarios should be adressed.

really trying to avoid having to hard-code accounts and passwords in a
configuration file since this seems insecure. For most hosting

If you want the box running some app component reboot without manual intervention (and leaving hardware crypto modules and such out of scope for now), then there will always be some file with a "secret" stored on the box:

a. a shell profile file setting an env var MY_SECRET=..
b. a private key for a public-private key thing
c. a (optionally salted) key for a symmetric crypto thing

If you loose that file, or someone gets access to that file, you're screwed.

Now, the question is: is it a good idea to make the whole Crossbar.io node configuration file a security sensitive file by having secrets (eg static WAMP-CRA secrets) right in that file?

Or would it be better to have the secret be only referred to in the node config (e.g. the name of an env var)?

I think the user should have the choice here.

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

Cheers,
/Tobias

environments you would probably make these environment variables so they
can be configured through the management website as well.

--
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/0b9eef7f-117b-4288-9014-89ebc295532c%40googlegroups.com
<https://groups.google.com/d/msgid/crossbario/0b9eef7f-117b-4288-9014-89ebc295532c%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

0 Likes

#3

Wow, as usual, thank you for all this detailed info, and some good current (and future) options. A few notes:

  • A lot of NodeJS application hosting providers allow you to set environment variables for your application through their management website often making them the preferred way to store configuration that may change (URLs to remote endpoints, etc) or secrets/keys, rather than having to re-deploy application files (since just login to these services to change a file manually). So with regard to what you were verifying, yes, and thank you for the link to the enhancement request to allow crossbar configuration settings to be read from an environment variable. It’s both a security thing (environment variables also don’t accidentally end up getting published to your Git repository like a Crossbar config file might :), but also an administration convenience.

  • Since I am not very familiar with Python, I was looking for a NodeJS solution, but I do realize there are samples already written in Python and its not very much code, so going polyglot and doing the authentication in Python so it can just run directly as a component is a good recommendation I will consider.

  • You recommended Domain Sockets in the other response you provided for me. I really don’t know anything about how they work so I guess I need to educate myself on them a bit more since they seem like they might be an easy way to resolve a few of my issues.
    Looking forward to deploying my first pilot applications with Crossbar and Autobahn in the coming year. Thanks again for your help.

···

On Monday, December 28, 2015 at 3:24:29 AM UTC-8, Tobias Oberstein wrote:

Hi Chris,

yep, a dynamic authenticator needs to authentiate itself too.

Am 26.12.2015 um 11:02 schrieb Chris Beckett:

Is the only way to authenticate the connection by the component trying

to register an authentication service by using static permissions? I am

If you mean, is this

  1. static WAMP-CRA (or WAMP-Ticket) with secrets literally contained in
    the node configuration file

the only way to authenticate a dynamic authenticator? Then, no, you can
also have:

  1. implement the authenticator in Python, run the component embedded in
    a Crossbar.io router worker and use a fixed authrole assignment
    (possible, since the embedded code is trusted/known anyway)

-> there is no issue since there is no secret anyway

  1. use Unix domain sockets for connecting the authenticator to the
    router, use filesystem permissions for security, and a fixed WAMP
    authrole again

-> there is no issue since there is no secret anyway


      1. are possible today with Crossbar.io release, while the following
        options are upcoming.

  1. static WAMP-TLS (TLS with WebSocket or RawSocket) for connecting the
    authenticator to the router and TLS client certificate authentication,
    and have the authid set from the cert, and the authrole from static config

-> there is no issue since the secret (the private key part) is not
exposed to Crossbar.io at all

Support for WAMP-TLS is in trunk:

https://github.com/crossbario/crossbarexamples/tree/master/authenticate/tlsdynamic

But: https://github.com/crossbario/crossbar/issues/569

  1. static WAMP-CRA with secrets from env vars

I agree (to what I guess you hint at) that it would make sense to be
able to use static WAMP-CRA authentication with secrets coming from
environment variables, instead of literal values in the node configuration:

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

(We have such option for listening TCP ports already …)

-> the issue is moved elsewhere (the secret needs to be on the box where
Crossbar.io, but is set outside the node config).

  1. static WAMP-cryptosign

Then I am working on WAMP-cryptosign, which is a new WAMP-level
authentication scheme based on Curve25519 crypto.

This will run over any WAMP transport, including non-TLS ones.

With WAMP-cryptosign, a node’s static authentication configuration will
have entries for client public keys:

“principals”: {

 "backend-inst01": {

    "pubkey": "rxVbS2hlekZOZVMlPjKwknj4LzHEiKxTpKQEjodJhAE=",

    "role": "backend-component"

 }

}

-> there is no issue since the secret (the private key part) is not
exposed to Crossbar.io at all

===

I think with 1. - 6. above, most scenarios should be adressed.

really trying to avoid having to hard-code accounts and passwords in a

configuration file since this seems insecure. For most hosting

If you want the box running some app component reboot without manual
intervention (and leaving hardware crypto modules and such out of scope
for now), then there will always be some file with a “secret” stored on
the box:

a. a shell profile file setting an env var MY_SECRET=…

b. a private key for a public-private key thing

c. a (optionally salted) key for a symmetric crypto thing

If you loose that file, or someone gets access to that file, you’re screwed.

Now, the question is: is it a good idea to make the whole Crossbar.io
node configuration file a security sensitive file by having secrets (eg
static WAMP-CRA secrets) right in that file?

Or would it be better to have the secret be only referred to in the node
config (e.g. the name of an env var)?

I think the user should have the choice here.

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

Cheers,

/Tobias

environments you would probably make these environment variables so they

can be configured through the management website as well.

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+unsub...@googlegroups.com.

To post to this group, send email to cros...@googlegroups.com

mailto:cross...@googlegroups.com.

To view this discussion on the web visit

https://groups.google.com/d/msgid/crossbario/0b9eef7f-117b-4288-9014-89ebc295532c%40googlegroups.com

<https://groups.google.com/d/msgid/crossbario/0b9eef7f-117b-4288-9014-89ebc295532c%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

0 Likes

#4

Hey Tobias,

It doesn’t look like AutobahnJS supports domain sockets as a connection option. Any samples you might be able to point me too to help with connecting NodeJS to Crossbar using domain sockets?

···

On Monday, December 28, 2015 at 3:24:29 AM UTC-8, Tobias Oberstein wrote:

Hi Chris,

yep, a dynamic authenticator needs to authentiate itself too.

Am 26.12.2015 um 11:02 schrieb Chris Beckett:

Is the only way to authenticate the connection by the component trying

to register an authentication service by using static permissions? I am

If you mean, is this

  1. static WAMP-CRA (or WAMP-Ticket) with secrets literally contained in
    the node configuration file

the only way to authenticate a dynamic authenticator? Then, no, you can
also have:

  1. implement the authenticator in Python, run the component embedded in
    a Crossbar.io router worker and use a fixed authrole assignment
    (possible, since the embedded code is trusted/known anyway)

-> there is no issue since there is no secret anyway

  1. use Unix domain sockets for connecting the authenticator to the
    router, use filesystem permissions for security, and a fixed WAMP
    authrole again

-> there is no issue since there is no secret anyway


      1. are possible today with Crossbar.io release, while the following
        options are upcoming.

  1. static WAMP-TLS (TLS with WebSocket or RawSocket) for connecting the
    authenticator to the router and TLS client certificate authentication,
    and have the authid set from the cert, and the authrole from static config

-> there is no issue since the secret (the private key part) is not
exposed to Crossbar.io at all

Support for WAMP-TLS is in trunk:

https://github.com/crossbario/crossbarexamples/tree/master/authenticate/tlsdynamic

But: https://github.com/crossbario/crossbar/issues/569

  1. static WAMP-CRA with secrets from env vars

I agree (to what I guess you hint at) that it would make sense to be
able to use static WAMP-CRA authentication with secrets coming from
environment variables, instead of literal values in the node configuration:

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

(We have such option for listening TCP ports already …)

-> the issue is moved elsewhere (the secret needs to be on the box where
Crossbar.io, but is set outside the node config).

  1. static WAMP-cryptosign

Then I am working on WAMP-cryptosign, which is a new WAMP-level
authentication scheme based on Curve25519 crypto.

This will run over any WAMP transport, including non-TLS ones.

With WAMP-cryptosign, a node’s static authentication configuration will
have entries for client public keys:

“principals”: {

 "backend-inst01": {

    "pubkey": "rxVbS2hlekZOZVMlPjKwknj4LzHEiKxTpKQEjodJhAE=",

    "role": "backend-component"

 }

}

-> there is no issue since the secret (the private key part) is not
exposed to Crossbar.io at all

===

I think with 1. - 6. above, most scenarios should be adressed.

really trying to avoid having to hard-code accounts and passwords in a

configuration file since this seems insecure. For most hosting

If you want the box running some app component reboot without manual
intervention (and leaving hardware crypto modules and such out of scope
for now), then there will always be some file with a “secret” stored on
the box:

a. a shell profile file setting an env var MY_SECRET=…

b. a private key for a public-private key thing

c. a (optionally salted) key for a symmetric crypto thing

If you loose that file, or someone gets access to that file, you’re screwed.

Now, the question is: is it a good idea to make the whole Crossbar.io
node configuration file a security sensitive file by having secrets (eg
static WAMP-CRA secrets) right in that file?

Or would it be better to have the secret be only referred to in the node
config (e.g. the name of an env var)?

I think the user should have the choice here.

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

Cheers,

/Tobias

environments you would probably make these environment variables so they

can be configured through the management website as well.

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+unsub...@googlegroups.com.

To post to this group, send email to cros...@googlegroups.com

mailto:cross...@googlegroups.com.

To view this discussion on the web visit

https://groups.google.com/d/msgid/crossbario/0b9eef7f-117b-4288-9014-89ebc295532c%40googlegroups.com

<https://groups.google.com/d/msgid/crossbario/0b9eef7f-117b-4288-9014-89ebc295532c%40googlegroups.com?utm_medium=email&utm_source=footer>.

For more options, visit https://groups.google.com/d/optout.

0 Likes

#5

Wow, as usual, thank you for all this detailed info, and some good
current (and future) options. A few notes:

  * A lot of NodeJS application hosting providers allow you to set
    environment variables for your application through their management
    website often making them the preferred way to store configuration
    that may change (URLs to remote endpoints, etc) or secrets/keys,
    rather than having to re-deploy application files (since just login
    to these services to change a file manually). So with regard to what
    you were verifying, yes, and thank you for the link to the
    enhancement request to allow crossbar configuration settings to be
    read from an environment variable. It's both a security thing
    (environment variables also don't accidentally end up getting
    published to your Git repository like a Crossbar config file might
    :), but also an administration convenience.

I've implemented the feature (in trunk). Here is how to use:

https://github.com/crossbario/crossbarexamples/tree/master/authentication/ticket/static#using-environment-variables

This works with WAMP-Ticket "ticket" configuration items, and WAMP-CRA "secret" configuration items.

  * Since I am not very familiar with Python, I was looking for a NodeJS
    solution, but I do realize there are samples already written in
    Python and its not very much code, so going polyglot and doing the
    authentication in Python so it can just run directly as a component
    is a good recommendation I will consider.

Yeah, that's the nice thing about polyglot: a pragmatic option to mix and match stuff ..

  * You recommended Domain Sockets in the other response you provided
    for me. I really don't know anything about how they work so I guess
    I need to educate myself on them a bit more since they seem like
    they might be an easy way to resolve a few of my issues.

It's like TCP sockets, but living in the filesystem. That is, they are not accessed via IP:port, but filesystem path.

Looking forward to deploying my first pilot applications with Crossbar
and Autobahn in the coming year. Thanks again for your help.

Awesome! Please let us know about your experiences! Or of course come back for more questions;)

Cheers,
/Tobias

···

Am 29.12.2015 um 06:03 schrieb Chris Beckett:

On Monday, December 28, 2015 at 3:24:29 AM UTC-8, Tobias Oberstein wrote:

    Hi Chris,

    yep, a dynamic authenticator needs to authentiate itself too.

    Am 26.12.2015 um 11:02 schrieb Chris Beckett:
     > Is the only way to authenticate the connection by the component
    trying
     > to register an authentication service by using static
    permissions? I am

    If you mean, is this

    1. static WAMP-CRA (or WAMP-Ticket) with secrets literally contained in
    the node configuration file

    the only way to authenticate a dynamic authenticator? Then, no, you can
    also have:

    2. implement the authenticator in Python, run the component embedded in
    a Crossbar.io router worker and use a fixed authrole assignment
    (possible, since the embedded code is trusted/known anyway)

    -> there is no issue since there is no secret anyway

    3. use Unix domain sockets for connecting the authenticator to the
    router, use filesystem permissions for security, and a fixed WAMP
    authrole again

    -> there is no issue since there is no secret anyway

    ---

    1. - 3. are possible today with Crossbar.io release, while the
    following
    options are upcoming.

    ---

    4. static WAMP-TLS (TLS with WebSocket or RawSocket) for connecting the
    authenticator to the router and TLS client certificate authentication,
    and have the authid set from the cert, and the authrole from static
    config

    -> there is no issue since the secret (the private key part) is not
    exposed to Crossbar.io at all

    Support for WAMP-TLS is in trunk:

    https://github.com/crossbario/crossbarexamples/tree/master/authenticate/tlsdynamic
    <https://github.com/crossbario/crossbarexamples/tree/master/authenticate/tlsdynamic>

    But: https://github.com/crossbario/crossbar/issues/569
    <https://github.com/crossbario/crossbar/issues/569>

    5. static WAMP-CRA with secrets from env vars

    I agree (to what I guess you hint at) that it would make sense to be
    able to use static WAMP-CRA authentication with secrets coming from
    environment variables, instead of literal values in the node
    configuration:

    https://github.com/crossbario/crossbar/issues/568
    <https://github.com/crossbario/crossbar/issues/568>

    (We have such option for listening TCP ports already ..)

    -> the issue is moved elsewhere (the secret needs to be on the box
    where
    Crossbar.io, but is set outside the node config).

    6. static WAMP-cryptosign

    Then I am working on WAMP-cryptosign, which is a new WAMP-level
    authentication scheme based on Curve25519 crypto.

    This will run over any WAMP transport, including non-TLS ones.

    With WAMP-cryptosign, a node's static authentication configuration will
    have entries for client public keys:

    "principals": {
          "backend-inst01": {
             "pubkey": "rxVbS2hlekZOZVMlPjKwknj4LzHEiKxTpKQEjodJhAE=",
             "role": "backend-component"
          }
    }

    -> there is no issue since the secret (the private key part) is not
    exposed to Crossbar.io at all

    ===

    I think with 1. - 6. above, most scenarios should be adressed.

     > really trying to avoid having to hard-code accounts and passwords
    in a
     > configuration file since this seems insecure. For most hosting

    If you want the box running some app component reboot without manual
    intervention (and leaving hardware crypto modules and such out of scope
    for now), then there will always be some file with a "secret" stored on
    the box:

    a. a shell profile file setting an env var MY_SECRET=..
    b. a private key for a public-private key thing
    c. a (optionally salted) key for a symmetric crypto thing

    If you loose that file, or someone gets access to that file, you're
    screwed.

    Now, the question is: is it a good idea to make the whole Crossbar.io
    node configuration file a security sensitive file by having secrets (eg
    static WAMP-CRA secrets) right in that file?

    Or would it be better to have the secret be only referred to in the
    node
    config (e.g. the name of an env var)?

    I think the user should have the choice here.

    https://github.com/crossbario/crossbar/issues/568
    <https://github.com/crossbario/crossbar/issues/568>

    Cheers,
    /Tobias

     > environments you would probably make these environment variables
    so they
     > can be configured through the management website as well.
     >
     > --
     > 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 crossba...@googlegroups.com <javascript:>
     > <mailto:crossbario+...@googlegroups.com <javascript:>>.
     > To post to this group, send email to cros...@googlegroups.com
    <javascript:>
     > <mailto:cros...@googlegroups.com <javascript:>>.
     > To view this discussion on the web visit
     >
    https://groups.google.com/d/msgid/crossbario/0b9eef7f-117b-4288-9014-89ebc295532c%40googlegroups.com
    <https://groups.google.com/d/msgid/crossbario/0b9eef7f-117b-4288-9014-89ebc295532c%40googlegroups.com>

     >
    <https://groups.google.com/d/msgid/crossbario/0b9eef7f-117b-4288-9014-89ebc295532c%40googlegroups.com?utm_medium=email&utm_source=footer
    <https://groups.google.com/d/msgid/crossbario/0b9eef7f-117b-4288-9014-89ebc295532c%40googlegroups.com?utm_medium=email&utm_source=footer>>.

     > For more options, visit https://groups.google.com/d/optout
    <https://groups.google.com/d/optout>.

--
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/49bbba77-a960-486a-841d-d7d54160039a%40googlegroups.com
<https://groups.google.com/d/msgid/crossbario/49bbba77-a960-486a-841d-d7d54160039a%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

0 Likes

#6

For the method 3: use Unix domain sockets for connecting the authenticator to the
router, use filesystem permissions for security, and a fixed WAMP
authrole again

how do I set up my config.json file? My authenticator is a java program under /auth.jar

"endpoint": {
   "type": "unix",
   "path": "/tmp/socket1"
}
how does crossbar know which my java is connecting via unix socket? 
and I am using jawampa crossbar client library to connect to crossbar like:
WampClientBuilder builder = new WampClientBuilder();

			builder.withConnectorProvider(connectorProvider)

			       .withUri(wampUrl)

			       .withRealm(realm)

			       .withSerializations(s)

				   .withInfiniteReconnects()

				   .withAuthMethod(new Ticket(ticket))

				   .withAuthId(authID)

				   .withReconnectInterval(5, TimeUnit.SECONDS);

currently, I am using ticket to authenticate the authenticator, but I do not want to have a static password to store in the config.json file.


-> there is no issue since there is no secret anyway 

<details class='elided'>
<summary title='Show trimmed content'>&#183;&#183;&#183;</summary>

On Saturday, December 26, 2015 at 2:02:00 AM UTC-8, Chris Beckett wrote:
> Is the only way to authenticate the connection by the component trying to register an authentication service by using static permissions? I am really trying to avoid having to hard-code accounts and passwords in a configuration file since this seems insecure. For most hosting environments you would probably make these environment variables so they can be configured through the management website as well.

</details>
0 Likes