Shibboleth and office 365 True SSO

[Tunturi Timo]

On 28/07/15 15:07, Aaron Howell wrote:
>
>> On 28 Jul 2015, at 9:09 PM, Tunturi Timo <timo.tunturi at aalto.fi> wrote:
>>
>> On 07/07/15 01:56, Aaron Howell wrote:
>>> The main problem we had with completely auto login was being able to auto detect a supported workstation (one that would have a Kerberos ticket) - as being a university we have to support more students BYOD than staff machines
>>
>> The most accurate and consistent solution to this problem I have found is greylisting of networks, browser user-agents and usernames.
> Laptops won’t work with that. I don’t find this a good approach for consistent user experience as the same machine will have different behaviour depending where it is located.

Laptops can be made to work with that. I'm really not an expert on the 
network side of things but I do know that we use VPN and 802.1X to drop 
laptops into suitable VLANs and to assign IP addresses for them. The end 
result is that the user experience is the same for the end user no 
matter where they use their laptops.

>> SPNEGO is only offered if the network and user-agent are found acceptable. The result of the nego authentication is ignored (and a login form presented) if the username is found to not be acceptable (such as an admin account or any other type of user account configured to be unsuitable for SPNEGO on the IdP).
>>
>> In general it's not a good policy to have corporate/staff/similar devices in the same networks as BYOD, anyway. If you have a situation where it's all mixed up it's a lot more difficult to solve the problematic situation than to avoid it to begin with, though.
> Also would not make sense for us, people still need to be allowed access to the same resources regardless of whether we provide the device or not. When you treat the entire user network as a potential threat - it is not actually so bad.

They have access to the same resources. Even from their personal devices 
at home, their personal mobile phones or whatever. They just need to 
login to the IdP with a username and a password.

> Too right there are no perfect solutions for all scenarios when the protocol is so narrow-sited - but we do what we can. The solution I proposed allowed a user to make a choice that they otherwise would not have the option for at all given our circumstances - so it has worked out well for those who choose to use it.

We have to make do the best we can with the environment we have. The 
button-and-cookie-based solution is a quite widely used one.