I'm not sure if you could call the following a best practice (more like a hack) but this seemed relevant here.
Bristol has a Google domain that supports a mixture of local SSO and direct Google authentication. As students leave they no longer have access to our local SSO but can continue to access their Google apps. Our SSO username matches their Google usernames. We allow the student to specify a Google password when they register. The main trick to making both authentication mechanism co-exist is that in the Google Dashboard under "Advanced Tools>Set up single sign-on" we specify a Network mask above where it says: "Network masks determine which addresses will be affected by single sign-on. If no masks are specified, SSO functionality will be applied to the entire network." Without setting a network mask every user *must* sign in via SSO (even if they manage to sign in with Google credentials first). To prevent this we limit SSO to *everybody* by specifying the Network mask as the following (notice both IP4 and IP6 masks): 0.0.0.0/1; 128.0.0.0/1; 2001:630:e4::/48 This means that it is now sufficient for users to sign in with just Google credentials if the user accesses via the Gmail front door ( https://mail.google.com) and specifies their Google username including the Google apps domain (e.g. [email protected]). Domain specific Google apps URLs continue to redirect to our local SSO as might be expected (e.g. https://mail.google.com/a/myuniversity.edu). I hope this is useful to somebody, Mark On 9 February 2013 23:58, Ed Hillis <[email protected]> wrote: > Thanks, Andrew! That does sound like it would do the trick here. > > Ed > > > On Fri, Feb 8, 2013 at 4:53 PM, Andrew Petro <[email protected]> wrote: > >> Ed, >> >> You seem to be thinking about the CAS server customization such that SSO >> sessions are initiated only when logging in to the portal. Otherwise, >> applications can use CAS for login, but doing so doesn't create SSO >> sessions. >> >> This can be a nice approach in that it helps users to understand, think >> about their single sign-on session, and helps them to understand where they >> might go to explicitly log out to end it. >> >> I get the idea that a customization to only begin an SSO session when >> logging into the portal is decently common -- I believe Rutgers is or was >> doing this in their CAS server, for instance; it's something Unicon's done, >> I believe, and that comes up in our CAS implementation plannings. >> >> Otherwise, you might simply want the portal to opt-out of itself >> benefiting from single sign-on by setting renew=true. Logging in to the >> portal would still create an SSO session. Logging into Google Apps would >> still create an SSO session. Logging in to Google Apps (or anything else) >> wouldn't yield a single sign-on session useful for logging in to the >> portal, though -- in all cases users would have to authenticate explicitly >> for the purpose of logging into the portal, whenever they log in to the >> portal. >> >> That requires no customization and might scratch your immediate itch. >> >> Kind regards, >> >> Andrew >> >> >> >> On Fri, Feb 8, 2013 at 10:06 AM, Ed Hillis <[email protected]>wrote: >> >>> We're integrating Google Apps with our CAS SSO, and we're also using >>> uPortal. I'm trying to arrive at the right combination of availability and >>> security, and would appreciate any thoughts. >>> >>> Currently, a user logged in to our portal can browse to mail.google.comand >>> be authenticated with their existing CAS ticket. That's fine. A user >>> who is not logged in to the portal can browse to mail.google.com, be >>> redirected to our CAS login, then redirected back to Google. The security >>> problem is that then, given our SSO environment, they are also >>> authenticated at the portal and will remain so until they close the >>> browser, even though they never "visited" the portal. >>> >>> Other scenarios to get around the problem that I can imagine but am not >>> sure how to implement: >>> >>> 1) The user only gets SSO authentication at Google if they already >>> expressly logged in to the portal. Otherwise they must authenticate at >>> Google, or perhaps be directed to the portal log in (log in to the portal, >>> not just do CAS authentication). >>> >>> 2) If the user has not already expressly logged in to the portal, when >>> they browse to mail.google.com, they go through CAS authentication but >>> get a ticket that can only be used for Google -- i.e., they are not >>> simultaneously authenticated in the portal. >>> >>> I'd appreciate hearing from others on this. Best practices? Did you go >>> with a different arrangement? Am I overlooking some basic CAS setup that >>> would solve the problem? I am new to both uPortal and CAS, so any level of >>> advice here would be helpful. >>> >>> Thanks, >>> Ed >>> >>> -- >>> Ed Hillis, Web Programmer >>> Southwestern University >>> 1001 East University Avenue, Georgetown, TX 78626 >>> 512.863.1066 [email protected] >>> >>> -- >>> You are currently subscribed to [email protected] as: >>> [email protected] >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/cas-user >>> >>> >> -- >> You are currently subscribed to [email protected] as: >> [email protected] >> >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user >> >> > > > -- > Ed Hillis, Web Programmer > Southwestern University > 1001 East University Avenue, Georgetown, TX 78626 > 512.863.1066 [email protected] > > -- > > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- "Paradoxically, the more time saving abstractions you are using the more you actually have to know." - Simon Willison -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
