Didn't consider using CAS for this as this multifactor auth is a requirement addressing human behavior more than security against an attack. I asked about this and pretty much they don't expect the user to physically be in the system all the time (They expect users sometimes even asking a coworker to fill stuff for them, as not everyone working for our clients need access to the app), so they added those mfas to keep actual users aware of what their accounts are being used for, with extra help of a log system. I still think is not really necesary (Just don't let others use your credentials, as a responsible user) but with clients we'll never know. Still, I like the idea of using CAS. Might be overkill, but I'd rather learn a proper way to handle this use cases.
El lunes, 21 de junio de 2021 a las 15:23:58 UTC-5, richard.frovarp escribió: > 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 [email protected] >> 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 [email protected]. > 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 > > <https://groups.google.com/a/apereo.org/d/msgid/cas-user/c1846401-6b12-4ead-9fa6-f8dcc2378153n%40apereo.org?utm_medium=email&utm_source=footer> > . > > > -- - 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/bb9cdcf1-b4c0-4d30-b1c6-b9ee5af02b12n%40apereo.org.
