Ok I’ve had a moment to prepare some screen caps/steps for you. Here’s how you do it…
Prerequisites
- You have a ziti overlay network deployed
- you’ve made two identities - one that will be the ‘server’ and one that will be ‘a client’
- you’ve enrolled the ‘server’ identity and have the .json file locally for use with the golang sample
Create the ONE config needed
You will only need an"intercept.v1" config for this - since you are using the golang sdk and “listening” on the ziti overlay network, you are NOT offloading traffic at your server. This means you only need “trust” inside your application - that’s amazing! Since you’re using a tunneling app at the client side, you will need the “intercept.v1” config. Let’s make that config now:
ziti edge create config golanghttp-intercept.v1 intercept.v1 '{"protocols":["tcp"],"addresses":["golanghttp.zitified"], "portRanges":[{"low":1234, "high":2345}]}'
Now let’s inspect what we’re saying here. We’re telling the overlay that you want a config, named golanghttp-intercept.v1 which is of type intercept.v1 that will allow a tunneling client to get a private DNS intercept named “golanghttp.zitified” on their device and we’ll allow a port range (i did that for fun) of ports 1234 through 2345
Create the service
Now you have the one config you need - now make the service
ziti edge create service golanghttp --configs 'golanghttp-intercept.v1'
Here we are instructing ziti to make a new service called “golanghttp” and to use the one config we just made “golanghttp-intercept.v1”
Authorize the “server” identity
You have already enrolled an identity that you want to ‘be the server’. Now you need to authorize the identity to ‘bind’ that service using a serivce-policy:
ziti edge create service-policy golanghttp-bind-policy Bind --identity-roles '@http.server.identity' --service-roles '@golanghttp'
We are telling ziti to make a service-policy named “golanghttp-bind-policy” of type “Bind” and authorizing ONLY the identity with the name “http.server.identity” to bind the services with the name “golanghttp”
Authorize the “clients” to Dial this service
Now we want to make it so identities can access this service. We do that by making a ‘dial’ service-policy:
ziti edge create service-policy golanghttp-dial-policy Dial --identity-roles '#http-clients' --service-roles '@golanghttp'
We’re telling ziti to make a service policy named “golanghttp-dial-policy” of type “Dial”. Allowing any identity which has the role of “http-clients” to dial the specific service named “golanghttp”
Wait a second - a ROLE???
That’s right - we don’t want to have to update this policy everytime a new identity wants access. That’d be horrible. So here we have used a ROLE instead. A role is an attribute added to an identity. Your mobile identity probably doesn’t have this role yet - let’s add it:
ziti edge update identity ${your.mobile.identity.name.here} -a "http-clients"
Is that it?
Yep. Assuming your mobile identity was already enrolled - by the time you read this you’ll probably notice a new service shows up on your device… Here’s what it looked like on my mobile when i did it:
You can see I now have a “cdaws-mobile” identity and it has access to one service. Now I can go to my browser and go to: http://httpserver.zitified:1234/add?a=4&b=7 and get a response from the zitified server in my tunneling app…
Conclusion
And that’s all there is to it… Since this is a discourse post - not a actual writeup, i might have messed up a step here or there or glossed over something - but I think I got all the steps correct.
You should be able to replicate the same… And next time you make an identity - since we used that roleAttribute idea - you can just make the identity with the attribute predefined and give that identity access to the same http server. Like this:
ziti edge create identity user newUser2 -a "http.clients"
That identity now will be authorized to use the http server you setup. neat stuff - right??? 