[SSO] Is it possible to make a service completely separated from other SSO services without require login every time (i.e. renew=true)

62 views
Skip to first unread message

Andy Ng

unread,
Apr 25, 2018, 5:20:01 AM4/25/18
to CAS Community
Hi all,

So I have done some research on this group and still doesn't find other with my use case, so I am asking for your help.

Assume we have services A, B, C and D:

B, C, D are normal SSO services, each one of them authenticate success, all BCD will login success.

As for A, I want that even when BCD is authenticated, user still needs to authenticate once more before getting to A.

At this point, theoretically all can be solved by "renew=true". And the new createSsoCookieOnRenewAuthn = false on 5.3.0 (https://github.com/apereo/cas/blob/v5.3.0-RC3/api/cas-server-core-api-configuration-model/src/main/java/org/apereo/cas/configuration/model/core/sso/SsoProperties.java)

However, the tricky part is that, next time when user go back to service A , I want the user to no need to authenticate again.

So it is basically like Service A is using another completely separated CAS server. Without actually using a separated CAS server (I don't want to make another server just for this).

One more requirement would be to single logout all ABCD, but I know how to do that so no advice is needed there.


Any advice would be appreciated, Thanks!

-Andy


Ray Bon

unread,
Apr 25, 2018, 1:03:38 PM4/25/18
to cas-...@apereo.org
-- 
Ray Bon
Programmer analyst
Development Services, University Systems
2507218831 | CLE 019 | rb...@uvic.ca

Andy Ng

unread,
Apr 25, 2018, 9:35:51 PM4/25/18
to CAS Community
Hi Ray,

Thank you for your response!

In the document [https://apereo.github.io/cas/5.2.x/installation/Configuring-Service-Access-Strategy.html] for ssoEnabled, pretty sure it is just "renew=true". 
Which is what I describe above (Service A needs to be login the next time it arrive CAS), not suitable in my case. 

However I do think if ssoEnabled is recommended, at least I should tried it in an actual CAS server instead of only theorizing. To see if it is what I want or not.

Also yes I have read about SSO Session Cookie, also read some CAS source code regarding SSO too (although not line by line).

Thanks you for helping me again.

- Andy

Carl Waldbieser

unread,
Apr 26, 2018, 9:43:18 AM4/26/18
to cas-user

There are probably a bunch of other problems associated with this idea, but couldn't you just serve the CAS service from 2 distinct domains? E.g. cas.example.net and cas.special.example.net? Since the TGT is scoped to a particular domain, if you point A's CAS client to the special domain, it should act like its own unique CAS instance.

Thanks,
Carl Waldbieser
ITS Identity Management
Lafayette College

----- Original Message -----
From: "Andy Ng" <lon...@gmail.com>
To: "cas-user" <cas-...@apereo.org>
Sent: Wednesday, April 25, 2018 5:20:01 AM
Subject: [cas-user] [SSO] Is it possible to make a service completely separated from other SSO services without require login every time (i.e. renew=true)

Hi all,

So I have done some research on this group and still doesn't find other
with my use case, so I am asking for your help.

Assume we have services A, B, C and D:

B, C, D are normal SSO services, each one of them authenticate success, all
BCD will login success.

As for A, I want that even when BCD is authenticated, user still needs to
authenticate once more before getting to A.

At this point, theoretically all can be solved by* "renew=true"*. And the
new *createSsoCookieOnRenewAuthn = false on 5.3.0*
I want the user to *no need to authenticate again*.

So it is basically like Service A is using another completely separated CAS
server. Without actually using a separated CAS server (I don't want to make
another server just for this).

One more requirement would be to single logout all ABCD, but I know how to
do that so no advice is needed there.


Any advice would be appreciated, Thanks!

-Andy


--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/f1002b09-eb19-477d-a733-13a6d45bad26%40apereo.org.

Misagh Moayyed

unread,
Apr 26, 2018, 2:23:49 PM4/26/18
to cas-...@apereo.org
It's unlikely that you can build this correctly in CAS without pain without accepting a few caveats that deal general session management. That said, you want to start reviewing what is called "SSO Participation" strategy components that basically decide how a service may opt in or out of SSO, a trigger for which is renew=true for instance, etc. You need to build one that looks into the TGT and queries its collection of services to find if a session exists for that app.  It would do things based on the presence or absence of that record. The outcome of the strategy determines whether user should be challenged or else. You can try to build a strategy that says: "If I have a record for BCD and no record of A, then challenge...or not. If I dont have a record, then challenge, ... or not".

--Misagh




On Wed, 2018-04-25 at 02:20 -0700, Andy Ng wrote:
Hi all,

So I have done some research on this group and still doesn't find other with my use case, so I am asking for your help.

Assume we have services A, B, C and D:

B, C, D are normal SSO services, each one of them authenticate success, all BCD will login success.

As for A, I want that even when BCD is authenticated, user still needs to authenticate once more before getting to A.

At this point, theoretically all can be solved by "renew=true". And the new createSsoCookieOnRenewAuthn = false on 5.3.0 (https://github.com/apereo/cas/blob/v5.3.0-RC3/api/cas-server-core-api-configuration-model/src/main/java/org/apereo/cas/configuration/model/core/sso/SsoProperties.java)

However, the tricky part is that, next time when user go back to service A , I want the user to no need to authenticate again.

So it is basically like Service A is using another completely separated CAS server. Without actually using a separated CAS server (I don't want to make another server just for this).

One more requirement would be to single logout all ABCD, but I know how to do that so no advice is needed there.


Any advice would be appreciated, Thanks!

-Andy


-- 
Ray Bon
Programmer analyst
Development Services, University Systems
2507218831 | CLE 019 | rb...@uvic.ca

--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.

Andy Ng

unread,
Apr 26, 2018, 9:46:23 PM4/26/18
to CAS Community, mmoa...@unicon.net
Hi all,

Thanks for all your replies!

To Carl: 
Last time I check, using both cas.example.net and cas.special.example.net, one of them will not work (sso will be broken for that domain). We need to specified the cas.host.name=cas.example.net, hence cas.special.example.net will have no SSO capability. I will try it once more in 5.3.0-RC3 to see if this behavior is changed, but I still thinks that this behavior would not work.

To Misagh:
Thank you for your suggestion, I will do some research on "SSO Participation". I am Ok with doing a more customization configuration. If I come up with something workable I will post it here for future reference.

However, are there any plan for this kind of feature being added to CAS in future build? If so, I might try to build it more generic, so it might one day can fit into CAS main source code. Thanks!

Cheers!
- Andy

Misagh Moayyed

unread,
Apr 27, 2018, 4:49:25 AM4/27/18
to cas-...@apereo.org
Thank you for your suggestion, I will do some research on "SSO Participation". I am Ok with doing a more customization configuration. If I come up with something workable I will post it here for future reference.

However, are there any plan for this kind of feature being added to CAS in future build? If so, I might try to build it more generic, so it might one day can fit into CAS main source code. Thanks!
If you do decide to build one and it's generic enough to consider side-effects and sacrifices, etc then it would be excellent to accept and merge the change. 


Andy Ng

unread,
Apr 27, 2018, 4:51:46 AM4/27/18
to CAS Community, mmoa...@unicon.net
Great, I will try to do it -Andy

Andy Ng

unread,
Jun 6, 2018, 10:24:44 PM6/6/18
to CAS Community, mmoa...@unicon.net
Just to do a update, due to the priority on my tasks on hand have changed, in short term I will not continue my development on "SSO Participation". Thanks.

-Andy
Reply all
Reply to author
Forward
0 new messages