>> So I'm going to talk about authentication. But before I do, I want to show you guys something
kind of cool. >> [INDISTINCT]
>> The--change the apple color blue? All right. I don't know how many of you guys know but--or
noticed we made a Wave post where we shared some UI mock-ups a little while here. So this
was some UI mock-up that I'll--that the Wave design I made as to how we would might consider
of redesigning Wave. This was made around Christmas time, you know, while Wave was working.
No one was actually intending to implement any of this stuff but I really, really liked
it and I was working as an intern at that time. So I thought it was cool, so I--so we've
now opened these mocks up. And, yeah, isn't it pretty, as in us?
>> Yey. >> So I managed to strong-arm one of my friends
into making this, which doesn't look very good at this resolution but this is an html
mock-up of exactly that, you know, or is that redesign. I've kind of changed around how
this bar works. We need to clean up the CSS a little bit, but, yeah--that like it's all
sort of nice. And if I can convince people who know enough, and maybe even myself, I
recommend that it would be really nice to get a design like this into Wave in a Box
and actually make it look really pretty. So we could take this and then put obviously
the undercurrent Wave client, you know, Wave panel into box, so, yeah. So that's what I
want to show you guys. Cool. >> It's great.
>> Thanks. All right. So I'm going to talk about authentication. So the way authentication
works--so I've implemented authentication in Wave in a Box and it's really something
simple. So if I pull up my likely running Wave in a Box instance, which I think is still
running. If it is. Yeah. So the--ah, that's not you. All right. So I can login. So this
is the login box, the sound authentication box. We toss and turned, like, we thought
about doing some kind of crazy authentication system but eventually settled on just really,
really standard, you know, you got a web app login. So the way this works is when you login
you get a cookie. The cookie has a hash card, which is--yeah, the cookie is in a hash on
the server. And in every request it looks up the hash and that's how I can tell who
she's logged in as. Really simple stuff. So if I ask Chrome to inspect this, I can look
at the storage and I've got no cookies. And if I sign in, then what this page does will--it
will store a cookie with the Java session. JAAS does that for us and then we'll redirect.
So, yeah, if I go back to the authentication page, then we can also--the page will also
supports a redirect URL so if any pages or any servers you guys decide to make you want
authentication, and if these is not authenticated you can bounce these onto the authentication
page, specify a redirect URL if they are authenticated. And once they are authenticated, it will just
redirect straight back to wherever it came from. So, really, really simple thing. Yeah.
I assume everyone's seen this before. Nothing new, it's all standard and quite boring. So
I want to show you guys how it works on the server's side, specifically because I think
a lot of people want to, you know, think about deploying this stuff in the enterprise. And
if you're deploying it in the enterprise, obviously, you probably want to hit single
sign on, use smart card authentication, use LDAP or whatever you want to do and will design
that--or design it to make it--really easy for you guys to do that but there's a few
bits and pieces that you need to understand. So I made a slide deck. And by slide deck
I mean I have a slide, which I'll show you. May be big. So for the server side authentication--the
server side authentication, we are using Java's JAAS, which stands for Java Authentication
and... >> Authorization.
>> Oh, and Authorization Service or Security something. Anyway, it's Java's--like it's
a standard way to do authentication stuff at Java. There's three concepts you need to
understand. Is this better? Yes. There's three concepts you need to understand to understand
JAAS and anything based on it. And there's three concepts. So you have here a subject,
the principal and a login module. So--and they're always really simple. The subject
is just the person so that's you or me or whatever. The principal is where it's more
[INDISTINCT]. The principal is the right that you have. So, for example, I've got a GitHub
account and I'm the subject when I log in to GitHub. And the principal on GitHub is
my--is the access to the Joseph G GitHub account. So that's what the principal means, it's like
your access. So if you've got an active directory server, then your principal is that you've
got a valid login on the active directory server. And finally, there's the idea of a
login module. And a login module will just provides a principal to a subject. So, a login
module--oh, sorry, yeah. So if you log in to a login module, the login module will say,
"Hey, to login, I'm going to need your active directory account name and domain and so on
and password." And then if you provide it that then the login module will provide the
subject that you've given it with the principals or whatever account that you specified. And
that's JAAS. That's the, you know, that's the theory behind it. So, the way it's implemented
in the server is it's really sort of as simple as we could possibly make it. Resolution.
There's a config file which is called JAAS.config. It just exists in the directory of the server.
This is a standard JAAS thing. So if you Google, like, JAAS example, you know, config file
or something, you'll get a whole bunch of different files. The files specifies, first
of all, that this is the way--it's Wave that you're logging into so that must stay the
same. Then it specifies the class name, fully qualified class name for the login module
that you want to use for your application. In this case where I've got a custom account
stall login module and the account stall login module pulls up your user from the database
and then checks your password. That's all it does. But if you want to have an LDAP-based
login module or something then it's reasonably easy. All you need to do is swap that out
for either your LDAP-based login module or one that someone's provided. And after that
you can specify some options. So if you're using active directory, then you specify the
domain and, you know, I think a shared secret with the LDAP provider or something. This
covers login modules, there's login modules for all sorts of different things. And I hope
somebody feels game to make a login module that will work with XMPP. And I might just
have to do something horrible like forwarding--just trying to login as the user that you've connected
as to the local XMPP server and then disconnect immediately but just to see if that user's
valid since there's no easy way to do authentication through XMPP. But if something like that happened
it would mean that Java integration would work a lot better. I mean, if people have--if
you're using a Java server, then your Wave users would also be Java users and all will
just work seamlessly. Anyway, so you can specify the login module and then you say that it's
required because users have to log in to that module to be able to log in and try on debugging.
So that's the JAAS config file. So I haven't actually played around with changing this.
I don't have an active directory server handy. I don't--I haven't done the XMPP yet. So if
anyone feels game--and please, please somebody feel game, multiple people feel game, play
around with this stuff. It should be pretty easy to do. Then that would be wonderful.
So, the login module is here and this--almost all of this stuff [INDISTINCT]. So if you've
got like, example, JAAS login module, you got almost this exact same class but with
a couple of things changed. And the main paydirt is this login function. And so for this login
module, what it says is--it says, "We're going to need a name and a password." So the login
module has given an object that it can query for the name or the password and the subject's
populated from the post data that the user sends. It says, "Ask the--ask the login data
for the user name and password," and then it goes to a series of steps where it tries
to grab the user account of the account store. Make sure that it's a human and not a robot
and then checks that the password matches. And if it does the user logs in. So there's
really only two classes you need to know to understand authentication. There's that one
and there's authentication server which does all of the actual work. And this, you know,
this class is--does the whole login page. And mostly it's really, really simple. Dopost
is the actual method that logs in and all it really does is call login and log in the
first thing as an exception if you're not logged at--or if, yeah, if your credentials
are bad. So if I jump to that, the login method is quite simple. It pulls out the parameters.
It creates an http request base call back handler, which is just a little custom class
to wrap these and the password how JAAS expects. And then, it creates context for the login
module stuff to happen in, which is just the JAAS thing. So as I've said, we're using Wave.
It pulls in the configuration file that was, you know, that's filed JAAS config. It gives
this name a password, it chose the, you know, the subject that we've created, which is for
the user that we're creating and then it tries to log in. And when it does that, it grabs
this context object and pulls the subject back out of it. And with the subject there's
one final function that you need to understand, which is that it causes, get login user. So
once the subject's logged in, the subject will have the principals that it's been given
by the login module. So the user's logged in and in this case the login module will
give it the--you know, you've logged in with a valid Wave account, you know, using the
data store principal. But if you were using, like, say, LDAP active directory then it would
give you a principal that's an active directory principal. This method grabs the principal
and then tries to reverse-engineer it and turn it back into a user ID, which is valid
on the Wave server. If you--so--and that's really, really simple. It's searches the principal's
one that's a participant principal which is the principal that were made for this and
then converts that back into an address. So, yeah, I would be delighted if an outcome of
this talk while here in front of you guys. Or if you feel like it, be game. Screw around
with this code. Add in--you know, try and try and make it work with JAAS. Try and--I'm
sorry--with LDAP. Try and make it with [INDISTINCT]. You might need to make a modification dysfunction
to make it understand different kinds of principles for the different login modules. And you may
also need to appear--make it so that when it gets the login address, say, if you're
using active directory, there might not already by a user in the account store which is a
Wave-specific thing, so you might have to create other users as well. But once it does
that it's really simple. And it just adds it to--it adds the user to a session manager,
which just means basically that everything else knows that that user is logged in and
using that cookie and Jetty provides all of the cookie management stuff. So that's how
authentication works with the client--of the Wave client. There's one other simple thing
that you need to understand. And when I say, simple, it's a bit dodgy and it's been hacky.
I'm sorry about this. A couple we won't touch on already because it's nasty. So when I was
designing all of these, I was hoping that all the browsers would support the one websocket
draft. And when they're connected by the websocket connection they would pass in the cookie that
they've been provided by Jetty straight into--straight into the backend. Unfortunately, this is something
that wasn't provided in previous drafts and none of the current browsers actually support
doing this. And none of the browsers will send the cookie in the websocket connection.
So as a workaround, I've hacked up a way to make it so that the server--so that the client
pulls the cookie token back out of the--I mean, you know, it pulls it up using JavaScript.
It grabs this cookie and it sends it using a message on the--on the IPC once the web
server connection establishes--is established. I prefer to be able to take this out if we
could, but I don't know when or if that will ever happen. But that's how, yeah, the websocket
connection's currently authenticated. If people have better ideas in how to do that then I'd
be open to things that aren't quite so nasty and, yeah, that would be good. Are there any
questions? No? Really? Come on, one. Come on. Drop your hand.
>> Well, I was [INDISTINCT]. >> Yeah.
>> Does that don't make sense then? I'm going to tell you really quickly. Are you guys happy?
All right, cool. Thanks. Yeah. So play around. Ask me any questions, I'm here all week.
>> Try the view? >> Sorry?
>> Try the view? >> Yeah, try the view.
eople have better ideas in how to do that then I'd be open to things that aren't quite
so nasty and, yeah, that would be good. Are there any questions? No? Really? Come on,
one. Come on. Drop your hand. >> Well, I was [INDISTINCT].
>> Yeah. >> Does that don't make sense then? I'm going
to tell you really quickly. Are you guys happy? All right, cool. Thanks. Yeah. So play around.
Ask me any questions, I'm here all week. >> Try the view?
>> Sorry? >> Try the view?
>> Yeah, try the