I'd also caution the use of this UID in a GET request. It sounds like it might be suspectable to cross-site scripting attacks. If I could figure out what the uuid, it would probably be easy to phish a user to an attacker site, and make the GET request
On Tue, Nov 20, 2018 at 8:35 AM Bengt Rodehav <[email protected]> wrote: > 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/ >>> >>
