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/6c240624-2724-4c5c-b660-033cede3a95cn%40apereo.org.
