I can't tell from a "should" or "should not" perspective. It breaks the MVC model to some extend.
Then on the other side your model is responsible to generate the most efficient business logic and database query possible. So letting the controller sort data by permission is not the way to solve this issue (it should never get any data the actual user is not allowed to see for security reasons). So this may be even worse than accessing the session in the model.
In my opinion (and how I would implement it if possible) I would add some special methods that take the user information as params (like def show_orders(current_user)) and return the results. That way you can keep the session handling in the controller (relevant if later you decide to use the model for another web interface or whatever) and still have optimized access.
Or add the access permission handling to the User model so you can access them like current_user.orders. If it's really simple permissions, you may be able to add this to the has_many declarations in Rails. Otherwise add some methods there.
The model is not limited to interaction with the database, the model is responsible for getting and manipulating data.
So, to your view and controller, it should make no difference, if the data comes from a database or from a webservice or is even totally random, therefore you should do it in model.
MVC is a presentation pattern, that only separates the different representation layers.
It does not mean, that model has to be a uniform mess of spaghetti code. Your model itself can be layered as well, but the controller should not know, where the data comes from.
A public method in your model can be structured like this (Pseudo-code), which can be called by your controller:
public MyDataClass getData(int id) {
WebServiceData wsData = WebService->getData(id);
DatabaseData dbData = ORM->getData(id);
return new MyDataClass(wsData, dbData);
}
WebService and ORM may need to be instances of interfaces that can be replaced by mocks via dependency injection, but your controllers and views do not have to change for testing purposes.
Best Answer
My gut tells me that you're correct to want to put some code into the Model. The fact of the matter is that while those are the functional/nonfunctional requirements on your application today - that could change. You could be required to implement a database on the next iteration of this project, or even worse the entire way you're storing data could get overhauled.
The fact of the matter is stuff changes. The better you modularize and abstract your code, the quicker you'll be able to adapt to change down the road. You'll also set yourself up for easier unit and integration testing, too. That's an important factor, because detecting problems before they become problems saves time and reputation.