Re: [cas-user] Re: Spring Security integration doubts (With JDBC)

['Richard Frovarp' via CAS Community]

CAS can do multifactor. It can also release a bunch of attributes about 
how the authentication went if you use the CAS 3 protocol. The service 
directing the individual to CAS can also request that a fresh login is 
used. Combined together, the service can be assured (so long as they 
trust the CAS IdP) that the authentication just happened. Submitting 
credentials again would likely not offer any increased security. And it 
also requires that each app handles the plain text credentials and needs 
to have the infrastructure to use it. Something like a Duo push on the 
SP side for MFA would be additional work for the user, but removes some 
of the infrastructure requirements on the SP.


On 6/21/21 3:02 PM, Fernando Bárcenas Martínez wrote:
i see. So it was indeed something I wasn't really understanding about 
how to handle the data, even when I was right about the authentication 
and authorization roles of CAS and Spring Security. That tells me that 
for my scenario, I will need to get a ticket for a meeting to rebuild 
some things, then.


And about the need to submit credentials again: I don't like it 
either, but I understand it's some sort of two-factor authorization. I 
got no vote on those design choices though.


Thank you very much for your insight and for the resources. I'll take 
a closer look to the Attribute Resolution too.


El lunes, 21 de junio de 2021 a las 12:13:33 UTC-5, Ray Bon escribió:

Cas can find username/password from a variety of sources and this
can be configured per service [1].
You can use the CAS 3 protocol [2] to release attributes to the
client application. And like username/password, attributes can be
obtained from more than one location [3].
There is also the facility to release the user's password [4].
This should be a last resort.

Spring and cas can point to the same table for user data. Cas is
for authentication, your application will have to perform
authorization. If you are returning attributes, you may need to
override or provide custom UserDetails and/or UserDetailsService
classes to handle the different source of attributes.

As for submitting username/password for 'important transactions',
this seems to be an architectural smell. If you know the user
(with attributes), what does the password give you? If requiring
the password is a decision out of your control, submitting it
automatically would circumvent this requirement.

Ray

[1]
https://apereo.github.io/cas/6.3.x/services/Service-Management.html

[2]

https://apereo.github.io/cas/6.3.x/protocol/CAS-Protocol-Specification.html#28-p3servicevalidate-cas-30


[3]
https://apereo.github.io/cas/6.3.x/integration/Attribute-Resolution.html

[4] https://apereo.github.io/cas/6.3.x/integration/ClearPass.html


On Saturday, June 19, 2021 at 9:24:34 AM UTC-7
barcmtz...@gmail.com wrote:

Good day! I've looked around for ways to enable SSO for our
web applications and CAS came out as an answer a lot, so I did
some research and gave it a try. So far, I managed to get the
server running and it generates de tickets using data for an
'access' database table. I have an issue with the redirects,
but that's not the topic of this.

The doubts I have are about the UserDetailsService and
UserDetails. Many of the tutorials and documentations I've
read touch into this breefly. I also didn't think it was much
necesary since using Spring Security formLogin is pretty much
the same concept, but as I tried to 'map' my needs to this,
things got confusing.

As I understand, CAS will use this 'access' table to
authenticatate, but that means that Spring will use it's own
'users' table to authorize. This kind of breaks my
requirements, as the idea of enabling SSO was to have a single
'users/access' table, not one for every webapp as we have
right now. The idea was to have the principal with important
data (principal name, password as it's required to enter it
for certain important transactions, autorithes for access and
a few other pieces of information that will let us know if an
user can access one webapplication or not), so having the
'users 'data to check for authorizations kind of make it seem
like there will be duplicated data as the info in 'access'
will need to match the UserDetails from 'users'... right?

Is this the way it should be or am I just not getting
something? To be fair, it would make my 

[cas-user] Re: Spring Security integration doubts (With JDBC)

[Fernando Bárcenas Martínez]

i see. So it was indeed something I wasn't really understanding about how 
to handle the data, even when I was right about the authentication and 
authorization roles of CAS and Spring Security. That tells me that for my 
scenario, I will need to get a ticket for a meeting to rebuild some things, 
then. 

And about the need to submit credentials again: I don't like it either, but 
I understand it's some sort of two-factor authorization. I got no vote on 
those design choices though.

Thank you very much for your insight and for the resources. I'll take a 
closer look to the Attribute Resolution too.

El lunes, 21 de junio de 2021 a las 12:13:33 UTC-5, Ray Bon escribió:

> Cas can find username/password from a variety of sources and this can be 
> configured per service [1].
> You can use the CAS 3 protocol [2] to release attributes to the client 
> application. And like username/password, attributes can be obtained from 
> more than one location [3].
> There is also the facility to release the user's password [4]. This should 
> be a last resort. 
>
> Spring and cas can point to the same table for user data. Cas is for 
> authentication, your application will have to perform authorization. If you 
> are returning attributes, you may need to override or provide custom 
> UserDetails and/or UserDetailsService classes to handle the different 
> source of attributes.
>
> As for submitting username/password for 'important transactions', this 
> seems to be an architectural smell. If you know the user (with attributes), 
> what does the password give you? If requiring the password is a decision 
> out of your control, submitting it automatically would circumvent this 
> requirement.
>
> Ray
>
> [1] https://apereo.github.io/cas/6.3.x/services/Service-Management.html
> [2] 
> https://apereo.github.io/cas/6.3.x/protocol/CAS-Protocol-Specification.html#28-p3servicevalidate-cas-30
> [3] 
> https://apereo.github.io/cas/6.3.x/integration/Attribute-Resolution.html
> [4] https://apereo.github.io/cas/6.3.x/integration/ClearPass.html
>
> On Saturday, June 19, 2021 at 9:24:34 AM UTC-7 barcmtz...@gmail.com wrote:
>
>> Good day! I've looked around for ways to enable SSO for our web 
>> applications and CAS came out as an answer a lot, so I did some research 
>> and gave it a try. So far, I managed to get the server running and it 
>> generates de tickets using data for an 'access' database table. I have an 
>> issue with the redirects, but that's not the topic of this.
>>
>> The doubts I have are about the UserDetailsService and UserDetails. Many 
>> of the tutorials and documentations I've read touch into this breefly. I 
>> also didn't think it was much necesary since using Spring Security 
>> formLogin is pretty much the same concept, but as I tried to 'map' my needs 
>> to this, things got confusing.
>>
>> As I understand, CAS will use this 'access' table to authenticatate, but 
>> that means that Spring will use it's own 'users' table to authorize. This 
>> kind of breaks my requirements, as the idea of enabling SSO was to have a 
>> single 'users/access' table, not one for every webapp as we have right now. 
>> The idea was to have the principal with important data (principal name, 
>> password as it's required to enter it for certain important transactions, 
>> autorithes for access and a few other pieces of information that will let 
>> us know if an user can access one webapplication or not), so having the 
>> 'users 'data to check for authorizations kind of make it seem like there 
>> will be duplicated data as the info in 'access' will need to match the 
>> UserDetails from 'users'... right?
>>
>> Is this the way it should be or am I just not getting something? To be 
>> fair, it would make my life easier to not change the 'users' tables of our 
>> webapps, but for some other stuff, like adding new users, will get more 
>> complex as i'd need to set up another datasource pointing to the database 
>> containing 'access'
>>
>

-- 
- 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+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/c1846401-6b12-4ead-9fa6-f8dcc2378153n%40apereo.org.

[cas-user] Re: Spring Security integration doubts (With JDBC)

[Ray Bon]

Cas can find username/password from a variety of sources and this can be 
configured per service [1].
You can use the CAS 3 protocol [2] to release attributes to the client 
application. And like username/password, attributes can be obtained from 
more than one location [3].
There is also the facility to release the user's password [4]. This should 
be a last resort. 

Spring and cas can point to the same table for user data. Cas is for 
authentication, your application will have to perform authorization. If you 
are returning attributes, you may need to override or provide custom 
UserDetails and/or UserDetailsService classes to handle the different 
source of attributes.

As for submitting username/password for 'important transactions', this 
seems to be an architectural smell. If you know the user (with attributes), 
what does the password give you? If requiring the password is a decision 
out of your control, submitting it automatically would circumvent this 
requirement.

Ray

[1] https://apereo.github.io/cas/6.3.x/services/Service-Management.html
[2] 
https://apereo.github.io/cas/6.3.x/protocol/CAS-Protocol-Specification.html#28-p3servicevalidate-cas-30
[3] https://apereo.github.io/cas/6.3.x/integration/Attribute-Resolution.html
[4] https://apereo.github.io/cas/6.3.x/integration/ClearPass.html

On Saturday, June 19, 2021 at 9:24:34 AM UTC-7 barcmtz...@gmail.com wrote:

> Good day! I've looked around for ways to enable SSO for our web 
> applications and CAS came out as an answer a lot, so I did some research 
> and gave it a try. So far, I managed to get the server running and it 
> generates de tickets using data for an 'access' database table. I have an 
> issue with the redirects, but that's not the topic of this.
>
> The doubts I have are about the UserDetailsService and UserDetails. Many 
> of the tutorials and documentations I've read touch into this breefly. I 
> also didn't think it was much necesary since using Spring Security 
> formLogin is pretty much the same concept, but as I tried to 'map' my needs 
> to this, things got confusing.
>
> As I understand, CAS will use this 'access' table to authenticatate, but 
> that means that Spring will use it's own 'users' table to authorize. This 
> kind of breaks my requirements, as the idea of enabling SSO was to have a 
> single 'users/access' table, not one for every webapp as we have right now. 
> The idea was to have the principal with important data (principal name, 
> password as it's required to enter it for certain important transactions, 
> autorithes for access and a few other pieces of information that will let 
> us know if an user can access one webapplication or not), so having the 
> 'users 'data to check for authorizations kind of make it seem like there 
> will be duplicated data as the info in 'access' will need to match the 
> UserDetails from 'users'... right?
>
> Is this the way it should be or am I just not getting something? To be 
> fair, it would make my life easier to not change the 'users' tables of our 
> webapps, but for some other stuff, like adding new users, will get more 
> complex as i'd need to set up another datasource pointing to the database 
> containing 'access'
>

-- 
- 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+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/6c240624-2724-4c5c-b660-033cede3a95cn%40apereo.org.

[cas-user] Hazelcast issue manifesting itself as high CPU

[Jason B. Rappaport]

Good morning.  Curious if anyone has seen this issue before with CAS running
a pegged CPU as a result of a Hazelcast hiccup.  

 

We run four CAS servers in each environment (QA and PROD):

*   2 x on prem 
*   2 x in the cloud

 

The on-prem CAS servers sit behind a load balancer as do the cloud CAS
servers.  Between campus and on-prem we have a dedicated connection.  

 

Over the last four months, just our cloud CAS servers (both QA and PROD at
the same time) have experienced pegged CPU.  We have been working with
networking to see if we are experiencing a networking hiccup, and thus far
we cannot find one.  

 

Within the log, on days we have encountered the issue, I see thousands of
these messages (just on the AWS QA and PROD CAS servers):

Initialized new cluster connection between /10.21.1.166: and onePremHost.edu/10.6.55.32:5701

 

When I talked to the Hazelcast folks, they indicated syncing service tickets
and the service registry via Hazelcast across our dedicated connection is
not recommended via the community edition of Hazelcast.  They recommended
using the Enterprise edition which uses message queues instead of TCP/IP
connections to sync the cluster.  

 

Questions:

1.  Is anyone using Hazelcast between on-prem and off-prem CAS servers
2.  Has anyone seen these error messages about Hazelcast and come across
a means to make the cluster more resilient?  

 

 

Thanks, Jay 

 

 



Jason Rappaport (he/him)

Identity and Access Management Analyst

Office of Information Technology

Email:    jason...@princeton.edu 

Office:  609-258-8464

 

 

-- 
- 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+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/BL0PR04MB5156C5A681F279D5364C521BCC0A9%40BL0PR04MB5156.namprd04.prod.outlook.com.


smime.p7s
Description: S/MIME cryptographic signature