By default, the credentials you use to login with (email) are translated into a principal that bears the same identifier (email) and that apps receive on the other end. They dont have to be the same. Conceptually, you can login with an email account but the way you resolve the principal can be altered to look at a different attribute unique per user and one that will not change. Of course, you'd have to evaluate to see where there exists such an attribute, and whether apps are prepared to receive it as the principal identifier instead of the email they are used to.
Starting with CAS 3.5, you have the ability to configure a specific attribute per application in the registry to be used as the username contained within the principal. Misagh ----- Original Message ----- From: "Michael Wechner" <[email protected]> To: [email protected] Sent: Tuesday, January 14, 2014 2:36:25 PM Subject: Re: [cas-user] Changing login ID via one service and sign in during the same session via another service Am 14.01.14 12:27, schrieb Misagh Moayyed: > Chiming in; that conceptually another alternative would be to resolve the > principal id by an attribute that user does not have the ability to change. > You can still authenticate by email, but the principal is identified by say a > 10-digit unique numeric value. This is simpler to set up, but impacts > integrated apps so may not be achievable depending on who/what is using your > CAS and how flexible they might be to this change. I am not sure I understand, can you explain what you are suggesting with an example or some more details? Thanks Michael > > > > > Misagh > > > ----- Original Message ----- > > From: "Michael Wechner" <[email protected]> > To: [email protected] > Sent: Tuesday, January 14, 2014 3:47:28 AM > Subject: Re: [cas-user] Changing login ID via one service and sign in during > the same session via another service > > Hi > > Thanks very much for clarifying. I guess you are refering to > > https://wiki.jasig.org/display/casum/single+sign+out#SingleSignOut-Howitworks: > > > which is sending a callback to all registered services/applications once > CAS receives a request for > > /cas/logout > > as a redirect by the management application of the browser of the user, > right? > > IIUC there is no other way to logout a user than redirecting the user's > browser to /cas/logout, right? > > I mean for example that the management application uses the original CAS > service ticket associated with the user > to make a logout request at the CAS webapp? > > Thanks > > Michael > > > > Am 14.01.14 10:16, schrieb Jérôme LELEU: >> Hi, >> >> Sorry if I was unclear, but the logout I'm talking about is the CAS logout, >> which notifies all the applications that the session for the user must be >> terminated. So the user is logged out from all applications (including the >> management one). >> Best regards, >> Jérôme >> >> >> >> >> 2014/1/13 Michael Wechner <[email protected]> >> >>> Hi Jérôme >>> >>> How do you "notify" the other applications that the user got logged out >>> from the management application? >>> >>> Thanks >>> >>> Michael >>> >>> Am 13.01.14 16:09, schrieb Jérôme LELEU: >>>> Hi, >>>> >>>> Our way : everytime a user change something in his management >>> application, >>>> we display a message like "Your change will be taken into account only >>>> after logout. Please click this link to logout". And the user is logged >>> out >>>> from all applications including the management one. >>>> Best regards, >>>> Jérôme >>>> >>>> >>>> >>>> 2014/1/13 Michael Wechner <[email protected]> >>>> >>>>> Hi Jérôme >>>>> >>>>> Thanks very much for your feedback. >>>>> >>>>> I guess we will logout the user from CAS, but keep the user signed in at >>>>> the service where he/she changed the ID. >>>>> But I am not sure yet whether this will have some unexpected >>>>> side-effects and need to sleep over it :-) >>>>> >>>>> Michael >>>>> >>>>> Am 13.01.14 14:47, schrieb Jérôme LELEU: >>>>>> Hi, >>>>>> >>>>>> We decided to force users to logout as the "safest and simplest" >>> solution >>>>>> for us. >>>>>> Best regards, >>>>>> Jérôme >>>>>> >>>>>> >>>>>> >>>>>> 2014/1/13 Michael Wechner <[email protected]> >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> We have two services which a user has access to, whereas as login ID >>> we >>>>>>> use the email address of the user. >>>>>>> Since the email address of a user can change, the user can change the >>>>>>> email address inside the service as follows: >>>>>>> >>>>>>> - First the user signs in to the first service (service1) with >>>>>>> '[email protected]' and changes his/her email inside this service to >>>>>>> '[email protected]', but which means the email address will also be changed >>>>> on >>>>>>> the backend/identity-management, BUT (currently) not inside CAS itself >>>>>>> >>>>>>> - The user decides to go to the other service (service2), but because >>>>>>> the user already has a valid session with CAS, he/she does not have to >>>>>>> provide the (new) credentials again, but the login request >>>>>>> >>>>>>> >>>>>>> >>> https://my.cas/cas-server-webapp-3.5.2/login?service=https://service2/index.html >>> >>>>>>> will return >>>>>>> >>>>>>> <?xml version="1.0" encoding="UTF-8"?><cas:serviceResponse >>>>>>> xmlns:cas="http://www.yale.edu/tp/cas";> >>>>>>> <cas:authenticationSuccess> >>>>>>> <cas:user>[email protected]</cas:user> >>>>>>> >>>>>>> which means in the case of service2 the user is signed in with the old >>>>>>> username, which does not work anymore with the backend. >>>>>>> >>>>>>> My question is whether there are any recommended ways to handle such a >>>>>>> situation? At the moment I can see the following possibilities: >>>>>>> >>>>>>> - Force logout after the user has changed the email address, and hence >>>>>>> user has to sign-in again with new email address >>>>>>> - Update the login ID inside CAS somehow (but I guess that's not >>>>>>> possible for security reasons) >>>>>>> - Provide some mapping from old to new email address, such that during >>>>>>> the same session also the old email is still valid. >>>>>>> >>>>>>> I have been searching quite a bit for similar topics, but have not >>> found >>>>>>> anything really, hence any hints/feedback is much appreciated. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Michael >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>> >>> -- >>> 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 -- 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
