<p>I have only recently started working with the MVC approach, so I suppose this is an easy one for you gurus here:</p>

<p><strong>Where do I put access control?</strong></p>

<ol>
<li>In a view? I don't want to have any logic besides switches and flags in my templates, so that sounds like the least viable option</li>
<li>In the model? Should each business object decide what data it will reveal about itself based on who's asking?</li>
<li>In the controller? That's where I have it now but it makes it hard to keep business rules consistent</li>
</ol>

<p>Or is there another option?</p>

This will depend on what framework you're using as that and the language will dictate a lot of the tools you have available to you.
From a high level, you should have access security configured at points-of-entry. And you should double-check access security at every level that could be considered autonomous or reused from multiple parts of your application (who knows if security was checked by your co-worker's portal that uses your logic layer? etc.). The other thing to worry about is data security, and that belongs as close to your data as possible (so, yes to your #2 above, but understand that it's separate).
This is akin to the difference between application logic and domain logic, which I'm fond of talking about. If there is any logic that is specific to one particular application (web app compared to a windows service, or whatever) then that logic should be defined in that application only. If some logic crosses the boundary between applications (is reusable between applications) then it qualifies as domain logic and should be defined in your model. Your applications can make use of domain logic, but they should not own it.