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/
