Using Shibboleth as an Intra-Realm SSO
A natural convergence towards use of Shibboleth for service providers inside the enterprise as well as outside exists. However, there are many things that a fully equipped local WebISO system is capable that Shibboleth cannot do as of version 1.3. The tight integration these systems are able to assume is not something that can be assumed by Shibboleth deployments. It is the eventual intent of the development team to make Shibboleth's SSO support as robust as possible.
If every SP and !IdP operational on campus are already members of a common external federation, the trust substrate provided by your federation may be sufficient. Simply create a separate set of attribute release policies, and possibly a new RelyingParty element to reference internal error page.
For most other deployments, the simplest way to implement intra-campus Shibboleth is by creation of a separate federation within a namespace delegated by MACE, such as urn:mace:supervillain.edu:intranet . Identity providers involved should treat this collection of sites as a separate relying party. Most variance in application behavior and attribute needs should be sufficiently handled with additional attribute release policies. Be cautious with attribute release, particularly if students or other non-enterprise entities will be allowed to operate resources behind SP's.
A separate metadata file will need to be created, signed, and hosted using metadatatool.