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
<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
<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
<https://apereo.github.io/cas/6.3.x/integration/Attribute-Resolution.html>
[4] https://apereo.github.io/cas/6.3.x/integration/ClearPass.html
<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 <https://apereo.github.io/cas>
- Gitter Chatroom: https://gitter.im/apereo/cas
<https://gitter.im/apereo/cas>
- List Guidelines: https://goo.gl/1VRrw7 <https://goo.gl/1VRrw7>
- Contributions: https://goo.gl/mh7qDG <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]
<mailto:[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/3e8c6d58-3acd-fabd-edf8-af3341625f13%40ndsu.edu.
