Thanks, Andrew! That does sound like it would do the trick here. Ed
On Fri, Feb 8, 2013 at 4:53 PM, Andrew Petro <ape...@unicon.net> 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 <hill...@southwestern.edu>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 hill...@southwestern.edu >> >> -- >> You are currently subscribed to cas-user@lists.jasig.org as: >> ape...@unicon.net >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user >> >> > -- > You are currently subscribed to cas-user@lists.jasig.org as: > hill...@southwestern.edu > 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 hill...@southwestern.edu -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
