So, I know the answer is probably "use the PAM primary factor", but
Currently, our authoritative authentication source is kerberos. We're
looking at making our IDM the authoritative source (and it would push
password changes out to krb, AD, etc).
We could point cosign at the IDM LDAP interfa
Thanks for the pointers. It would be a lot more approachable to do new
implementations of cosign if there were a spec document like this one:
http://jasig.github.io/cas/development/protocol/CAS-Protocol-Specification.html
One of the key differences between Cosign and CAS seems to be the
implement
While its a different configuration option from the vhost's SSL setting,
they don't have to be separate certificates (as long as the cosign server
recognizes the CA that signed the browser facing cert)
Liam
On Friday, February 6, 2015, Tom Boutell wrote:
> Thanks for the pointers. It would be a
On 2015-02-06 17:11, Tom Boutell wrote:
> One of the key differences between Cosign and CAS seems to be the
> implementation of separate SSL certificates for Cosign's back-channel.
> I'm curious what the improvement in security is there. It could be
> left over from the era when the public sites mi
Interesting. In the CAS scheme, the login server redirects the browser
back to the client website, with a unique ticket. The client website
then calls back to the login server to verify the ticket is
legitimate, and the login server responds with the username and other
metadata.
Since the login se
On 2015-02-06 20:22, Tom Boutell wrote:
> Since the login server never redirects with a ticket to any site but
> one of its whitelisted client websites, and always with https, and the
> client website always uses https to call back to the login server, I
> don't see a risk of man-in-the-middle atta
