Being able to Single Sign-On between trusted environments is a great feature, although it also can allow a black hat access to additional environments. In other words, Single Sign-On has both pros and cons.
End User experience - Allowing a user to seamlessly access resources on different environments. Nothing annoys a user more then being asked multiple times for credentials. These credentials could be the same credentials or a different set of credentials.
Managing multiple sets of credentials - Having to manage multiple sets of credentials can lead to unsafe user practices, like writing down passwords or using the same passwords across multiple environments.
Security hole - If a hacker somehow gets access to one environment, they may be able to single sign-on into a second environment
Things to keep in mind:
When implementing single sign-on between environments, it is important to keep track of Auth-Level. If a user logs into an environment with username/password, they cannot be allowed to single sign-on into a resource protected with a higher level of authorization (I.E. two-factor).
If a credential is compromised in one environment, security personnel must be vigilant in closing down any single sign-on avenues from that compromised environment. You may be vigilant with your security procedures/policies, but now you are relying on another environments security procedures/policies (that you may not control).
Any security token used to assert a users identity needs to be secure, and only share data that has been approved and is relevant to the request..
It is recommended that certain resources not be accessible via single sign-on. For example, user profile edits where email could be changed (which is used for a forgotten password feature).
Single Sign-On is crucial to end-user experience. In today's world end-users demand a simple experience, or may go to another competitor. Thought needs to be put into any single sign-on solution prior to implementation.