Great advice Philip - and yes you're right; the access token is both the username and the password. I think this is best practice in a token based authentication scenario.
I think I can come up with a way to link the access token to a list of IP addresses. Just a question, the code you wrote where you check "(if(!allowedIPSs.get...)". In what method would I do that? And what existing filter is best to extend? I actually think that our approach is pretty common in a REST scenario. Perhaps even common enough for Shiro to support it... /Bengt Den tis 20 nov. 2018 kl 10:54 skrev Philip Whitehouse <[email protected]>: > Okay.. > > I’m pseudo-coding here but: > > Firstly your accessToken is not just your username. It’s also your > password. The reason for this is that it’s the secret that authenticates a > user. You currently aren’t storing a real username. The IP address isn’t > secret - it’s not your password. It’s just a filter. > > Tbh the deficiency in Shiro here is that there’s no AuthToken-based Token > implementation. That would have encouraged the right solution from the > start. > > What you want is a config like the following: > > accessToken1=accessToken1,publicApi > accessToken2=accessToken2.publicApi > > and then separately > > [allowedIPs] > accessToken1=ip1,ip2 > > and then your filter says: > > if(!allowedIPs.get(accessToken).contains(ip1) { > throw new AuthenticationFailedException(); > } > > What you need to do is implement a Shiro Ini reader that help you do the > second bit. There might even be existing IP filters for Shiro out there. A > quick search looks promising. > > Best, > > Philip Whitehouse > > On 20 Nov 2018, at 07:38, Bengt Rodehav <[email protected]> wrote: > > Sorry for being unclear. I'll try to explain better. > > We have a REST API that partners to us can access. It is a simple http/GET > based protocol that returns JSON data. Authentication is being done via a > parameter "accessToken" in the URL (https://....?acessToken=123). The > access token is similar to a user. We don't require a password since the > accessToken itself is a random GUID. We do, however, only allow access from > known IP addresses (white listing). Generally speaking, this is a public > site so the firewall restricts no one. But this API needs to be restricted > to known IP addresses. > > Currently I have created a filter (I have subclassed AuthenticatingFilter) > with my own createToken() method. In that method, I extract the access > token and the IP address (either from the ServletRequest's getRemoteAddr() > or from the "X-Forwarded-For" header). I then create a > UsernamePasswordToken with the access token as the user and the IP address > as the password. > > The number of users accessing this service is not very high so it is easy > to maintain them in the ini file as follows: > > [users] > accessToken1=123.123.123.123,publicApi > accessToken2=456.456.456.456,publicApi > > ...where "publicApi" is the role I require for accessing this service. > > This approach is really easy and works but it only allows for one IP > address per access token which is a limitation for us. Some customers need > to access our service from multiple servers and sometimes from an IP > address range. > > So I need another solution. One solution is of course to use the firewall > for white listing. We do that for a number of other services where we only > allow access from our partners. However, in this case the site is public > except for this exact call. This makes it hard for us to use our firewall. > Also, it would be nice to maintain the access tokens and the IP addresses > in one place. Otherwise the risk is very high that the firewall will, after > a while, not be synced with the access tokens. > > I am very open to other approaches. I just took an easy first route that > seemed to work fine - for a while... > > /Bengt > > > > > > > > > Den tis 20 nov. 2018 kl 07:21 skrev armandoxxx <[email protected]>: > >> Hey ... >> >> Please explain what would you like to achieve (your use case) .. we will >> try >> to help you how to implement it ;) .. Sorry I'm lost too ... >> >> Regards >> Armando >> >> >> >> -- >> Sent from: http://shiro-user.582556.n2.nabble.com/ >> >
