Authenticating the Authenticator

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

[Tobias Oberstein]

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

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.

[Chris Beckett]

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.

> <mailto:crossbario+unsub...@googlegroups.com>.

[Chris Beckett]

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:

> <mailto:crossbario+unsub...@googlegroups.com>.

[Tobias Oberstein]

Am 29.12.2015 um 06:03 schrieb Chris Beckett:
> 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

> > an email to crossbario+...@googlegroups.com <javascript:>
> > <mailto:crossbario+...@googlegroups.com <javascript:>>.

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

> <javascript:>
> > <mailto:cross...@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>.

[Jun]

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