It's not uncommon for websites to show/hide navigation based on what roles a user has. This become more problematic when the links being shown/hidden are links to other websites. Each site then needs to know about the others and any time you deploy a new site as part of the suite you need to update each app to add it, and maintain the logic based on roles for which items to show hide. A solution i've seen for this is to create a webservice and ask it what nav you should be showing, I'm not a huge fan of pull based services so this has always bugged me.
I am however a big fan of Dependency Injection and while this issue isn't exactly all that related, it occurred to me that your login portal (WS-Fed, OAuth or whatever) can kind of be used like a DI Container to inject things into dependent apps. The change is extremely simple, instead of the IdP (just) telling apps what roles the user has, they also pass through a list of navigation items to display for that user. The nav then becomes a fairly dumb component that just reads the claims passed in and shows them. Thus centralising all the logic around what to show to what user, and considering the IdP normally has a list of relying parties anyway it's not exactly new information to it. Of course it doesn't really work for internal links or links to systems not controlled by the IdP.
This is great when different roles have a different subset of apps they have access to, you can use this technique to create modular user portals that reuse common functionality/apps but still make it feel like a single portal (as long as look and feel is common). Where it becomes really neat is when you start looking into beta testing / A/B testing / slow rollouts where you can replace entire applications for specific user groups with a newer version instead of a big bang approach. Again not really suitable for in app features (especially if you have multiple different toggles) but for that you can fall back to roles.
