| *** WiKIDLogBot (~WiKIDLogB@ec2-174-129-6-100.compute-1.amazonaws.com) has joined #wikid | 13:13 | |
| card.freenode.net | Topic for #wikid is: If no one is here, please try email, the nabble forums: http://www.wikidsystems.com/support/support/wikid-forums | 13:13 |
|---|---|---|
| card.freenode.net | Users on #wikid: WiKIDLogBot @nowen finalbeta proprietarysucks SEJeff_work remix_tj | 13:13 |
| nowen | proprietarysucks: do you have some WiKID questions? | 14:46 |
| *** manonst (406a83fe@gateway/web/freenode/ip.64.106.131.254) has joined #wikid | 17:05 | |
| manonst | hello, anyone not idling? | 17:05 |
| nowen | yep | 17:05 |
| manonst | yay :) | 17:05 |
| nowen | ;) | 17:06 |
| manonst | i'm looking at wikid for an enterprise deployment and was curious about running multiple domains on a single server | 17:06 |
| nowen | ok | 17:06 |
| nowen | not a problem. but you either need multiple external ips or a dns solution | 17:07 |
| manonst | from what i could gleam from the (quite limited) documentation, domains are identified either via a server code, or a dns entry of the domain indentuy | 17:07 |
| nowen | yes | 17:07 |
| manonst | ok, with regards to the dns solution - how does this work for mobile clients? | 17:07 |
| manonst | aren't they hardcoded to point to wikidsystems.net? | 17:07 |
| nowen | we create a dns entry for you. | 17:07 |
| nowen | so, it has to run through our dns service | 17:08 |
| manonst | is there an API or programitc way to do this? | 17:08 |
| nowen | what do you mean? | 17:08 |
| manonst | i mean, if I have a bunch of domains I am setting up, can I make an API call to wikid to create the DNS entry? | 17:08 |
| manonst | or is it an email and wait kind of thing? | 17:08 |
| nowen | currently the latter. | 17:09 |
| manonst | I see. | 17:09 |
| nowen | how many domains will you need? | 17:09 |
| manonst | Unknown. I work for a hosting company, each client opting for 2FA would need their own domain | 17:09 |
| manonst | initially, like 30 | 17:09 |
| nowen | hmm | 17:10 |
| nowen | we could pre-populate dns for you too | 17:10 |
| manonst | yeah all of them would resolve to the same IP address | 17:10 |
| manonst | so if you could resolve a block of domain identifiers for us that would work | 17:10 |
| nowen | are you sure you need a separate domain for each one? | 17:10 |
| nowen | we can do that | 17:11 |
| manonst | I am not sure. I haven't played with it too much as of yet, just working out the logistics | 17:11 |
| manonst | but I do like the idea of flexibility on a per client level | 17:11 |
| nowen | sure | 17:11 |
| manonst | Can pre-registration work with mobile clients as well? | 17:12 |
| nowen | not at this time | 17:12 |
| manonst | just taking some notes... | 17:12 |
| manonst | I assume its possible to group users and associate a radius attribute with that group such that it can be returned to a firewall for use as a tunnel group? | 17:14 |
| nowen | yes | 17:14 |
| nowen | via the under-documented groups tab | 17:14 |
| nowen | ;) | 17:14 |
| manonst | is there any reporting on those users/groups? | 17:14 |
| manonst | typically a client administrator will need to revalidate access on a recurring basis (perhaps anually) | 17:15 |
| nowen | there can be a ton of logging done. I'm not sure about the reports specifically tagged via groups | 17:15 |
| nowen | so, you would want an admin to review group membership? | 17:15 |
| nowen | a list of users in that group? | 17:15 |
| manonst | I would want a client admin to see a list of users in each group and the associate radius attribute (tunnel group) | 17:16 |
| manonst | for their domain only | 17:16 |
| nowen | ok | 17:16 |
| manonst | ideally client's would be able to login and manage users under their domain only and have no other access | 17:16 |
| manonst | i'm not sure if this is possible | 17:16 |
| nowen | so, we have group functionality in the API. we would just have to make sure that the admin can do that | 17:17 |
| nowen | if it requires extending that api that's easy | 17:17 |
| nowen | the API already allows for multi-tenancy | 17:17 |
| manonst | excellent | 17:17 |
| nowen | we can develop an admin tool for you also | 17:18 |
| manonst | eventually I would like everything polished under our portal, but a one off admin tool which delievers the functionality we need would certainly suffice in the short term | 17:19 |
| nowen | what language is your portal written in? | 17:19 |
| manonst | today it's php/perl | 17:19 |
| manonst | but we are moving (in the next 1-50 years ;) ) a completly new portal | 17:20 |
| nowen | we have a php network client. it's not our best/fastest language, but we can do it | 17:20 |
| nowen | really, though the network client api is designed to be distributed. | 17:20 |
| manonst | distributed in what manner? | 17:21 |
| nowen | well, just that the network clients need a cert to talk to the WiKID server, so they can be anywhere | 17:21 |
| manonst | ok...another question | 17:25 |
| manonst | can pre-registration be done on a per domain level? | 17:25 |
| nowen | it must be | 17:25 |
| manonst | ok. and can the pre-registration details contain the group as well? | 17:26 |
| manonst | sorry for some of these questions, I have't installed the product. All of this is being driven by reading all of your docs and watching the video | 17:27 |
| manonst | I'm getting a server setup now to take it for a spin | 17:27 |
| nowen | hmm. that may need to be added. you can register with a group and pre-reg, so it can be done | 17:27 |
| nowen | no problem | 17:27 |
| *** proprietarysucks has quit (Quit: Lost terminal) | 17:27 | |
| manonst | ok, so it's not out of the box but easy enough to implement? | 17:28 |
| nowen | shouldn't be too hard | 17:28 |
| manonst | So if we spin up a new client that knows all the users which need 2FA in advance and which server access they should have (via tunnel groups) | 17:29 |
| manonst | then I want to get all those users into the system in one shot | 17:29 |
| manonst | And then to manage the solution going forward, I want each client to be able to create users based on registration codes, and potentially be able to tie backend auth on a per domain level | 17:30 |
| nowen | yes. all you need to do is get them the pre-shared secret in some secure manner for pre-reg | 17:31 |
| nowen | then each customer gets a network client interface - they can manage their own users | 17:31 |
| manonst | this interface, does it need a dedicated IP address? | 17:32 |
| nowen | each client gets a domain and a network client. the network client is associated with infrastructure or whatever | 17:32 |
| manonst | yeah the network client would likely be radius communicating to the firewall | 17:33 |
| manonst | what I mean is the web based interface - it's all a single web portal correct? and not an instance per domain running a different IP or port? | 17:33 |
| nowen | the requirement is that they have their own .p12 file from the server. so, you can have it all in one page, but each one needs it's own session with the server | 17:36 |
| nowen | currently ;) | 17:36 |
| nowen | though for security, that's probably the best way | 17:36 |
| manonst | I'm not sure I've conveyed my question cleary. | 17:37 |
| manonst | The interactive web portal which admins use to manage WiKID - does this interface support multi-tennancy? | 17:38 |
| nowen | yes | 17:38 |
| nowen | ohh. ok | 17:39 |
| nowen | let me clarify too | 17:39 |
| nowen | so, here's what we would recommend - 1 connection to the WiKID server. Then each user's access is controlled by the web app | 17:41 |
| nowen | so it bob@customer1.com logs in, he can manage customer1.com users only | 17:41 |
| nowen | s/it/if | 17:41 |
| manonst | Ok and this management is via a custom web app, not via the built-in one? | 17:42 |
| nowen | yes. | 17:42 |
| nowen | the WiKIDAdmin is not limited to single domains, but this one would be | 17:42 |
| manonst | Ok, and you mention that you could build this for us -- out of the goodness of your heart / included with the commericial pricing, or charged via professional services/consulting? | 17:43 |
| nowen | charges via pro services. The wauth api packages are all lgpl. you can also do it yourself | 17:43 |
| manonst | Ok fair enough. | 17:44 |
| nowen | we work well with other developers | 17:44 |
| nowen | and we like feedback. | 17:45 |
| nowen | we're working on a "cloud" offering like this. pre-populating dns entries is a good idea for it | 17:45 |
| manonst | Cloud offering would be even better | 17:46 |
| nowen | you mean where we host it? or it's on amazon? | 17:47 |
| manonst | we'll we can do hosting as well - but when stuff is made for 'cloud' it generally contains the feature sets needed for hosting companies | 17:48 |
| nowen | yes I see what you mean | 17:48 |
| manonst | It would be nice if this custom webapp could query a web services interface to find all portal users under customer1, then the customer admin could assign those users to predefined groups. | 17:49 |
| manonst | Then those users could do self-registration using their portal password | 17:49 |
| nowen | ok - so call your customer DB and get a user list | 17:50 |
| nowen | put those users into a group and create the pre-reg data | 17:50 |
| manonst | isn't pre-reg differnt than self-reg? | 17:50 |
| manonst | i thought i read something about an AD backed self-reg | 17:51 |
| nowen | self-reg can be done with anything. their existing username and password from that same web services interface | 17:51 |
| nowen | oh - yes - sorru | 17:52 |
| nowen | I misread your last statement | 17:52 |
| nowen | yes - exactly self-ref | 17:52 |
| nowen | reg | 17:52 |
| manonst | so can self-reg work with mobile clients? | 17:52 |
| nowen | yes | 17:52 |
| manonst | what's the process? they type in the server code which would use DNS to point to wikisystems.net, which resolves back to me | 17:53 |
| nowen | yes | 17:53 |
| manonst | then they get a registration code, but how to they associate that with their username via self-reg? | 17:53 |
| nowen | then they are prompted to set their pin | 17:53 |
| nowen | they would login to the web-app or some portion there off with their existing creds | 17:54 |
| nowen | and enter the registration code | 17:54 |
| manonst | and can self-registration be combined with prepopulating users in groups? | 17:55 |
| nowen | so, all users registered are added to a group? | 17:55 |
| nowen | that we can do now | 17:55 |
| manonst | What I mean to say is: The client admin sets authorization in advance | 17:59 |
| manonst | So they see a list of all users they manage and can set them in various groups - the groups allow 2FA and set the tunnel group accordingly | 18:00 |
| manonst | if the user is not in a group, they get no 2FA access | 18:00 |
| nowen | hmm | 18:00 |
| manonst | at this point users exist but don't have a token assigned to them | 18:00 |
| manonst | then use self registration to associate the token to the existing user | 18:00 |
| nowen | let me try to run through it | 18:01 |
| manonst | using this setup, an admin to do all of the work in advance, and whenever the user gets around to registering the token it will immediately start working | 18:01 |
| nowen | the client admin pulls a list of users from your web services. | 18:01 |
| manonst | correct | 18:01 |
| nowen | they assign certain users to a group for 2fa | 18:02 |
| manonst | to one or more groups | 18:02 |
| manonst | different groups grant differnet server access | 18:02 |
| nowen | ok | 18:02 |
| nowen | then the users have to self-register. when they do, the process also puts them into their groups in WiKID which are associate with return attributes. | 18:03 |
| nowen | then they have 2fa access and are in groups | 18:03 |
| nowen | does that sound about right? | 18:03 |
| manonst | not exactly what I was saying but it could work as well | 18:04 |
| manonst | I was expecting the assigning of users to groups initially to be groups in WiKID | 18:04 |
| manonst | and then the self registration would just associate the token to the existing user in the existing group | 18:04 |
| nowen | yes. a bit different but I think putting some of the logic outside the WiKID server is more secure | 18:05 |
| nowen | and, to be clear, there isn't really a user in WiKID until the registration occurs | 18:05 |
| manonst | Ok, I was under the impression the registration was a registration of a token, not necessarily a user | 18:06 |
| nowen | well, yeah, it's a two-step process | 18:06 |
| manonst | but given that contraint I can see why would need/want the users & groups to be externally maintained and then populated in WiKID during the registration process | 18:07 |
| nowen | pin is set and the account is created/username is registered, account is activated | 18:07 |
| manonst | so does this all sound feasible with the current API? | 18:07 |
| nowen | yes | 18:07 |
| manonst | k | 18:08 |
| manonst | brb | 18:09 |
| manonst | so given this workflow, would the groups pre-exist in the WiKID with the radius attribs? | 18:32 |
| manonst | and then during the self-reg, the web app would query the portal DB to determine the user's group membership? | 18:33 |
| nowen | that would make the most sense, if possible. | 18:33 |
| nowen | I am assuming that you have sold them a set of rights | 18:33 |
| nowen | so, we would set those up in WiKID. | 18:33 |
| manonst | yep that's what I think as well | 18:37 |
| *** proprietarysucks (~nathanr@static-96-247-50-178.lsanca.fios.verizon.net) has joined #wikid | 19:07 | |
| proprietarysucks | hi, did anyone get my question about a set up service? | 19:08 |
| nowen | proprietarysucks: no. what was it? | 19:08 |
| proprietarysucks | do you guys offer a set up service? | 19:09 |
| proprietarysucks | for community edition? | 19:09 |
| proprietarysucks | google sso 1 domain | 19:09 |
| nowen | we don't do a lot of paid support/install stuff | 19:10 |
| proprietarysucks | gotcha | 19:10 |
| proprietarysucks | you have a typo in your install script | 19:11 |
| proprietarysucks | [-f | 19:11 |
| proprietarysucks | instead of [ -f | 19:11 |
| proprietarysucks | breaks in sh, bash | 19:11 |
| nowen | oops. which script is that? | 19:12 |
| proprietarysucks | the very first one, the set up script | 19:14 |
| proprietarysucks | may I also recommend adding iptables to dependencies, since wikid will crash and burn without it | 19:15 |
| *** finalbeta_ (~finalbeta@ip-83-134-173-214.dsl.scarlet.be) has joined #wikid | 19:15 | |
| nowen | wikidctl setup? | 19:15 |
| nowen | hmm | 19:15 |
| *** finalbeta has quit (Ping timeout: 240 seconds) | 19:17 | |
| proprietarysucks | grep -lr '[-f' * | 19:22 |
| proprietarysucks | or rather | 19:23 |
| proprietarysucks | grep -lr '\[-f' * | 19:23 |
| proprietarysucks | it's wikidserver_config.sh | 19:23 |
| proprietarysucks | I think | 19:24 |
| proprietarysucks | yeah there's at least one in there | 19:24 |
| nowen | ok got that one | 19:25 |
| proprietarysucks | I find your scripts odd as well, they are in sh but call for bash as their shell | 19:26 |
| proprietarysucks | and have some places where " " would be recommended in sh using [ ] | 19:26 |
| proprietarysucks | for example line 79 on that file | 19:26 |
| proprietarysucks | if [[ ! $PFILE ]; then -> if [[ ! "$PFILE" ]; then | 19:27 |
| proprietarysucks | essentially you're going to always want "$myvar" inside of [ ] | 19:27 |
| nowen | hmm. well, they have been around for a while have had a few people in them | 19:27 |
| proprietarysucks | understood | 19:28 |
| nowen | some of them me ;) | 19:28 |
| proprietarysucks | usually you would write something in SH for portability, which would only be possible if you're using SH as the shell | 19:28 |
| proprietarysucks | in this case you're using SH but calling BASH. also since you can be pretty damn sure any system that can run wikid can have bash, I'd recommend just rolling with bash | 19:29 |
| proprietarysucks | anyways I'm blabbering, too much coffee | 19:29 |
| proprietarysucks | thanks | 19:30 |
| nowen | np | 19:30 |
| nowen | thanks for the feedback! | 19:30 |
| *** proprietarysucks has quit (Quit: Lost terminal) | 21:11 | |
| *** nowen has parted #wikid (None) | 23:02 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!