In that case I'd have an object to handle login, search, etc. The FC dishes off the request to the appropriate command (controller), which then requests the necessary processing and responses from appropriate model objects. Based on the responses from the model, it determines which view is needed and passes appropriate data to that view.
In other words, I wouldn't have a login command, I'd have (for example) a UserController command that looks at the request, sees it needs to check the login and get search results, calls the Login and Search objects appropriately, and does what it needs to with the responses.
Also, on the authorization: you may want to simply use an authorize() method in each controller; for restricted access areas, make a call to the appropriate auth object and return that response; for non-restricted areas, just return true. I'm not at all sure this is the best approach, but it does work well. As long as the actual auth logic is separated in an auth (or user) object, the core code doesn't get duplicated, but the access-level security stays where it belongs, in the controller. (It could easily and sometimes rightly be argued that the security belongs in the view, but this, I think, is quite a different topic.)
I just realized there's a discussion going on about the topic of authorization in view vs. controller here