Hi,
I agree there is a problem with the OAuth confirmation screen. Please open
a JIRA for this issue.
Though, the OAuth server support is not built like the SAML or OpenID
support : it's not embedded into the webflow, there is no dedicated
extractor, service... It's "just" a controller with sp
> The OAuth timeout problem, the SAML assertion timeout problem, and the CAS
> service ticket problem, would all be solved by CAS issuing the [OAuth token
> / SAML assertion / service ticket] after the user clears the warning /
> authorization screen hurdle.
Thanks for mentioning this solution, An
The OAuth timeout problem, the SAML assertion timeout problem, and the CAS
service ticket problem, would all be solved by CAS issuing the [OAuth token
/ SAML assertion / service ticket] after the user clears the warning /
authorization screen hurdle. The login flow can have as much user
experience
> it makes me think that I face the same "problem" on the confirmation page
> when using the OAuth server wrapper for CAS. The user has to grant access to
> his profile before the service ticket expires.
That's actually an interesting use case. I don't think we have
considered protocol interact
Hmm...well I will have to experiment more with this.
On Wed, Feb 6, 2013 at 9:08 AM, Marvin Addison wrote:
> > I don't think the assertion expiration was the problem here because I
> > watched the student replicate the problem (login to google was moments
> after
> > logging in to CAS). I was an
> I don't think the assertion expiration was the problem here because I
> watched the student replicate the problem (login to google was moments after
> logging in to CAS). I was and am still able to replicate the issue with my
> own account.
You don't have to linger on the warn page long. The def
I don't think the assertion expiration was the problem here because I
watched the student replicate the problem (login to google was moments
after logging in to CAS). I was and am still able to replicate the issue
with my own account.
Curtis
On Wed, Feb 6, 2013 at 8:55 AM, Marvin Addison wrote:
> the problem ended up being that the "Warn me before logging me into
> other sites." checkbox was checked.
Interesting. It's likely that the SAML assertion expired while the
user was lingering on the warn page. The more general problem of
ticket expiration while lingering on the warn page is a k
Marvin, the problem ended up being that the "Warn me before logging me into
other sites." checkbox was checked. Not sure if that constitutes a bug or
if that is the desired behavior so I thought I would follow up.
Curtis
On Fri, Jan 18, 2013 at 12:33 PM, Marvin Addison
wrote:
> > Did I understa
> Did I understand you to say that if I download and configure a
> copy of the latest version that I might be able to view the payload info? If
> this is the case, I might give that a try.
That's correct, latest 3.5.x version. Set the following logger to see
all SAML protocol data passing in and o
Marvin, thanks for the suggestions. Yeah, I am definitely trying to get the
payload info...and yes so far turning up logging isn't helping. I will try
org.opensaml. Did I understand you to say that if I download and configure
a copy of the latest version that I might be able to view the payload inf
> When I look at the CAS logs,
> everything looks normal here too...the student is getting authenticated
> correctly. The same student has no issue logging into any of the other
> casified services. The only thing I can conclude is that for some students,
> Google is having trouble reading the SAML
Is the last couple days, we have had a few students indicated that they are
having trouble logging into their Gmail mail account. We are running CAS
3.3.5 with the SAML authentication to sign into Google. Last evening, I
watched one of the students try to login via her tablet (same student is
also
13 matches
Mail list logo
