login page w/ Social IDP options

[Cantor, Scott]

On 9/22/11 11:49 AM, "Liam Hoekenga" <liamr at umich.edu> wrote:
>
>I was talking to my boss, and he expressed a desire to update our login
>page w/ options to log in using shib, or a number of social networks.  He
>wants to preserve as much of the existing flow as possible.  (In a past
>message where I'd talked about something similar, Scott had responded
>that 
>trying to "maintain the illusion" was a bad idea, and probably cause
>problems in the long run).

I think that was in your question on hiding guest accounts from the SPs? I
guess this is somewhat similar, and I guess I'd be equally skeptical of
the argument that it should be both "allowed for stuff generally" and "of
course blocked somewhere other than the SP for case A-Z".

I get why people would accept Google and Facebook, but I don't get why it
isn't the SP's job to care and block access if you do.

But this is a hard problem. I would argue it's much easier if the SP just
supported the protocols needed directly (which would be easier if they'd
stop changing), but some people would argue the gateway idea is even
better. It just depends what you care the most about.

All I really believe for sure is that you should architect gateways to be
invisible if they serve no user-relevant function, and that discovery,
however you do it, should be one step. I shouldn't have to pick from 2-3
separate lists to choose Google, but simply pick that instead of the other
options (Michigan, other InCommon sites, Facebook, whatever).

>Ideally, campus SPs shouldn't have to change their sites / applications.

I think that's unrealistic, even if "change" just means "implement
appropriate authorization controls". Of course, having reasonable controls
in place up front should mean they don't have to change, but it isn't
something I would assume or try and work around.

> 
>Ideally, this would be centrally provided, so it's something that would
>"just be available" to people who'd already deployed Shib.

Thus a gateway.

>We could add the social login options there.. but if we did, we'd need to
>extend the SSO such that it could accept authentication from those
>sources (which would be a problem in itself).

Meaning you just want the SPs to be able to accept new identies rather
than trying to link outside identities to local ones in your IdM.

>We were trying to figure out if the SSO could maybe identify requests
>from 
>Shib (via referrer?) and only display those extended options to Shib auth
>requests.

It seems to me the discriminator might be which SP it is, not whether it
happens to be coming from a SAML SP.

>I'm not sure how feasible it is to turn the login page for our SSO into a
>DS (and still allow it to be used as the authenticator).. and even if it
>/is/ possible, I'm not sure that it's a good idea.  It seems like an
>intersitial page would be required - it could be attractive and well
>camoflauged, but it'd still need to be there.

Whatever I think of it, "click here for other stuff" on the main login
page is a pretty common approach actually.

>I'm looking for comments / suggestions / ideas (someone willing to have
>an 
>extended discussions would be most appreciated).

As Peter alluded, this is ground being covered extensively by the social
identity activity, and campuses have posted various approaches to the wiki.

-- Scott