Adam:
Hi everyone. Welcome to The Check with Joseki Tech. I'm Adam Steadley, our president here at Joseki Tech. And joining me today is Dan, our vp of applications development, and Vasil, our lead engineer on the hub boost project. And today we're going to be talking about our adding SSO into our framework. at we're hosting and we certainly don't want those to be wide open to the Internet, so we needed to lock them down. So that was the requirement. So Dan, what was the approach we decided to take on this?
Dan:
Well, we had the web app there and we wanted to get it protected. We weren't really interested in putting up, you know, any form of basic authentication or our own login form. We wanted to do something quick. Cookie cutter. Spring boot already has ways for you to tie in single sign on. So for example, if you're already authenticated with LinkedIn or Google or GitHub, that authentication you can single sign on into your own app with. So it's not too terribly difficult to set up. There's recipes all over the web for it. Spring boot itself tells you how to do it. My part, I have the keys to the castle. So I was able to go into our Google admin console, create an app. Essentially you kind of got to register your app. And I provisioned a client id and a client secret.
Dan:
These were the things that Vasily would need to do the basic configuration and then from there, all the heavy lifting he did.
Vasyl:
My work is written code and so I will share some code.
Dan:
Yeah.
Vasyl:
So as already we using Spring Boot. Spring boot starters that has quite good infrastructure and a lot of supported libraries that will provide different functionality. One of the functionality is security that came from spring security sub model and therefore it has spring boot security after configuration as well as different providers for use of that. Okay, so all we needed to add to the project, just this dependency we're using malware dependency management and this is how the dependency adding looks like. So after adding this, like literally four lines of code, we got all the libraries, everything we need. The next step is actually to configure security. We need to define which endpoints we should protect and which are not. So this is done by written some Java code. This is in I create separate class security that is responsible for this.
Vasyl:
So this is very easy. We just say authorize using these request matchers. Like everything to IP is permitted for now. Everything we have is permitted for now. But everything else requires authentication, right?
Dan:
A couple of things that are public resources that we're going to want to be available outside the security. Yeah.
Vasyl:
And we use our slugin with defaults also we use specific logout handler. I will show you why we need it here. But with default logout it also works expected. So this is very easy configuration where we define everything. But still the question is how to define the case and security case that Dan provides me. So for that it just simply defines them inside of our configuration file which is simply application yaml. Like the library we fetched with Mallon expect this case to be here. After this case are defined, after this application discovers them, they start using. So we have client id which is here, and client secret which is here. After defining this we can start the application and each it will run. So that's pretty all library Java codes that define what and where and configuration with secrets.
So when we go to localhost our application, we see this screen. Like Daniel already mentioned, we don't do any our custom login screen, we actually do nothing because everything is provided by library and it's very easy and fast to integrate. So we use Google authentication screen and I'm simply select user I want to login if I need to login. So I'm using my current Google authentication for this and I got here. So that's it. Can you talk a little bit about.
Dan:
The standard oauth authentication flow? What happened there? Just from a request response perspective?
Vasyl:
Yeah, it's also a very interesting story behind this. First of all, OAuth is standard that provides to login to one site using credentials or authority from another site. In this case we use our Google authority to login to our application which right now running on localhost.
Dan:
So you requested a resource that was protected and this jumped in the way and said no, no, you need to be authenticated and then sent you down the standard authentication SSO flow and you were already authenticated in Gmail or Google somewhere else, which is why you didn't have to enter credentials. You just need to pick your account here, right?
Vasyl:
Yes, exactly. So these libraries add filters that simply monitoring every resource that is requested to application and that filter actually check whenever I have permission to check to access those or another page or resource. And if I don't have yet, it redirects me to Google's website. You can see in other slides here that I'm on Google site, it redirects me there and I should as Google user provide such access.
Dan:
So Adam, you might be wondering about we have two things here that are going on, really, authentication and authorization. All we're tackling initially with the SSO is the authentication. We're just proven that they're authenticated. Later we'll come back with another story and we'll do authorization. So we'll probably use Rbac or some kind of roles or permissions so that you have certain capabilities that you're allowed to do in the system as a certain level user.
Vasyl:
Yeah. Okay. And few more notes right now. After user got login to our website, a library got special authorization code from Google and you see it as authorization proves that I have access to these resources. And once I will access this website and next time I will simply have this. Because behind this simply page reload network. If we go to network and select simply documents and I will reload this, it remembers the session. But for example, if I will forget.
Adam:
The session, it'll do the Oauth handshake again.
Vasyl:
Yes, this is how it behaves. So it simply check the session and if the session is tailored it checks me to login again. Also if you don't want to use this website anymore, you can look out and this will simply invalidate the token. A few more notes about invalidation token by default spring security with default build does not invalidate this token. It's simply logout from current application. So and I still want to ensure that if person click logout, he actually logged out. So for providing this additional, but I believe essential functionality that is not came by default, I wrote special logout handler which I registered here, custom logout handler. And inside of this handler I simply took authentication and using authorized client service as a service that also came with libraries simply revoke these tokens.
So that's why I ensure the token is invalid and therefore person need to re authenticate herself again.
Dan:
So this is actually kind of a known issue if you will, with SSO is there's no standard token invalidation endpoint, is that correct?
Vasyl:
Yeah. The idea behind this that once you logged in you will always use this website like your own personal, you don't need to login into Facebook, into Google every time you open browser, every next day. So this is like common practice to keep these authorities as long as you need and therefore this oauth flow even have the strategy of invalidation tokens but no clear way of logout because when you click logout you need to define from where you actually want to log out from this website that running on localhost or from entire Google. That's like good question. And we need to define this explicitly.
Adam:
A couple of questions about what our next steps look like. Right now we know that who logged in, but as long as you've got a Google account, you can log into our page. So better than nothing, but certainly the first step. Are we logging on our side? Who's logged in? Do we write that to a file at least about who's logged into our site?
Vasyl:
No, it probably will require additional work because I don't recall if spring security by default show active users.
Dan:
Yeah, we're not doing anything specifically. If spring is doing something, probably it is. If we turn up the level, it's going to show us the token and everything.
Adam:
Yeah. So I would scratch in a little bit so that when we're here on this upload page, we can log on our side. Who uploaded the account? The guys logged in. So we know who it is. That'll be a good thing to log. That just generically sounds like something interesting. Then the next layer is we're probably going to want to limit it to Joseki Tech. Is that configuration or how are we going to go about that? Keen?
Vasyl:
Okay, a few answers here. First of all, checking whenever it's only for just architecture or for everyone is in application settings at Google admin console.
Dan:
So we already provisioned a group, I think, and we only added a couple of resources from Joseki.
Adam:
So that's already built in is just. We understand that it's a group, so it's not wide open. I can't log in as adam@steadily.com and have it work. That'll bounce me.
Dan:
Correct. Oh, cool.
Adam:
Okay, so we're fully locked down at this point. You're only let in if we put you on the magic list.
Dan:
Yeah. You have to be included to the group.
Vasyl:
Cool.
Adam:
Yeah, that's super useful. So we also don't have to worry about other Joseki.
Dan:
Yeah, we're going to be doing some other fancy things too, like right now with SSO. Some of the magic here is it saved us from having to do anything. Right. We didn't have to carve out any tables or do any extra user services or anything. Little bit of configuration and dependency. And we've got authentication in another heartbeat. When you want to do that authorization there, we'll probably have a table and we might even do a refresh token, something to track the permissions. Right. That gets a little bit more involved. So step one was just protecting things, you know, putting a gate up, and step two will be getting the authorization in place.
Adam:
Sounds really good. Okay, I think. Great first step toward getting things locked down. Thanks, everyone, for reviewing, and hopefully we can bring some more tech tips along the way.
Dan:
Thank you so much.