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.
