Ok, it has been a little while for me but I’ll try. I have worked with both SimpleSAMLphp and Shibboleth implementations of SAML. SimpleSAMLphp being the easier of the two to setup demo IdPs and SPs.

Anyway, when your user visits another SP’s domain that uses the same IdP that they have already authenticated to then you can either have your IdP re-authenticate them by the cookie on their machine or force them to enter their username/password again. You can also configure how long their login session lasts on the IdP.

The way you figure out their identity on the second SP is basically the same way that you would on the first SP. You can configure what user data will be sent to each SP individually, each SP can be sent the same user data or custom user data depending on the needs of that SP.

EDIT
RE: Do I send his SAML assertion tokens along with the redirect request? Or does the second Service Provider need to contact the ID Provider all over again?

I believe the SAML spec allows both. I remember that I could have the user visit the second SP’s domain where the SP would then hit the IdP to get the assertion tokens or you can have the user visit the IdP first with a query string identifying the second SP and then redirect the user to the second SP along with the assertion tokens.

EDIT#2 By the way I would recommend NOT writing your own implementation of SAML unless you have a lot of time and other team members helping. Heck, last I checked Shibboleth didn’t have a full implementation of the SAML spec, and they are the “SAML people.” In addition, you may run into interoperability issues if you plan on supporting 3rd party SPs or IdPs if you have a custom written implementation.

You actually don’t have to do any of the work if you don’t want to. I agree with the previous comment — don’t build a SAML library — they exist in many shapes and forms.

Read this to start with: https://wiki.shibboleth.net/confluence/display/SHIB2/UnderstandingShibboleth

SSO is out of the box with Shibboleth so you don’t have to even monkey with trying to re-invent the wheel either. If you want a full walk through of this, read the training material which will walk you through an entire install for the IdP and a Drupal SP:

https://spaces.internet2.edu/display/ShibInstallFest/Shibboleth+Workshop+Series+-+Linux+Identity+Provider+%28Centos+6.2%29

You will need to work out how you want to register the trust for your ‘internal federation of IdP & SP’ but that is a small piece of the puzzle in the grand scheme of things.

So your questions are:

But what happens when I redirect the user to another Service Provider?
Ans: the SP software will intercept the request and validate if the user is logged in. If not, redirection occurs. If so, the SP configuration will be the gate for attributes being released (usually after the IdP releases the attributes to it).

How do I ascertain the user’s identity there?
Ans: see above. Choose your identifier wisely. Highly recommended to NOT use email as the identifier. TL;DR is email changes and it’s a bad choice.

Do I send his SAML assertion tokens along with the redirect request?

Ans: you don’t care. Let the Idp+SP software deal with it. Read the docs if you need to go deeper into what happens, but app folks don’t need to be bothered with it.

Or does the second Service Provider need to contact the ID Provider all over again?

Ans: The IdP is consulted to retrieve attribute information when the user has signed in properly.

The ‘I’m tasked with developing an SSO system’ likely needs some planning and scale considerations (e.g. technology, # of sites etc, user audience plus a number of other planning questions). It would be healthy to nail those down 🙂

I was looking at answers to this question and it still took a minute before something really obvious jumped out at me. If the user is already logged in at the idP then when you move from one service provider to the next, each will contact the idP and the idP will see the same cookie it left from the first time they logged in.

So if you are using SP initiated SSO then there is no extra work that needs to be done to move between SP sites. Below is some paraphrased sample code lifted from Component Space’s .net SAML implementation for the idP site. Note that after you’ve logged in once, then when you move between SP’s this code will recognize that you’re already logged in and skip the if block that sends you to the login page:

public class SAMLController : Controller
{
    const string ssoPendingSessionKey = "ssoPending";

    public ActionResult SSOService()
    {
        // Either an authn request has been received or login has just completed in response to a previous authn request.
        // The SSO pending session flag is false if an authn request is expected. Otherwise, it is true if
        // a login has just completed and control is being returned to this page.
        bool ssoPending = (bool?)Session[ssoPendingSessionKey] == true;

        if (!ssoPending || !User.Identity.IsAuthenticated)
        {
            string partnerSP = null;

            // Receive the authn request from the service provider (SP-initiated SSO).
            SAMLIdentityProvider.ReceiveSSO(Request, out partnerSP);

            // If the user isn't logged in at the identity provider, force the user to login.
            if (!User.Identity.IsAuthenticated)
            {
                Session[ssoPendingSessionKey] = true;
                FormsAuthentication.RedirectToLoginPage();
                return new EmptyResult();
            }
        }

        Session[ssoPendingSessionKey] = null;

        // The user is logged in at the identity provider.
        // Respond to the authn request by sending a SAML response containing a SAML assertion to the SP.
        // Use the logged in user name as the user name to send to the service provider (SP).
        // Include some user attributes.
        string userName = User.Identity.Name;

        SAMLIdentityProvider.SendSSO(Response, userName, new Dictionary<string, string>());
        return new EmptyResult();
    }

    // ... other methods such as SLO
}