date:20190221

Re: [cas-user] Re: CAS 5.2.2 with MFA using Google Authenticator / GAuth

2019-02-21 Thread Jeremy Van Rooyen

Thanks for your feedback Mickaël,

For the second part I'm presented by the qrcode and 5 scratch codes. When I 
scan the qrcode my Google Authenticator app on phone accepts it. 

Then I click on register and enter the token displayed by the Google 
Authenticator app and it says --> "*Credentials are rejected/invalid and 
authentication attempt has failed.*"

This is what I see in the CAS log file:

*DEBUG [org.apereo.cas.authentication.PolicyBasedAuthenticationManager] - 
*
*DEBUG [org.apereo.cas.authentication.PolicyBasedAuthenticationManager] - 
*
*DEBUG 
[org.apereo.cas.adaptors.gauth.GoogleAuthenticatorAuthenticationHandler] - 
*
*DEBUG 
[org.apereo.cas.adaptors.gauth.GoogleAuthenticatorAuthenticationHandler] - 
*
*DEBUG 
[org.apereo.cas.adaptors.gauth.GoogleAuthenticatorAuthenticationHandler] - 
*
*DEBUG 
[org.apereo.cas.adaptors.gauth.GoogleAuthenticatorAuthenticationHandler] - 
*
* WARN 
[org.apereo.cas.adaptors.gauth.GoogleAuthenticatorAuthenticationHandler] - 
*

It sounds to me that when I use the scratch codes it is stored in the 
mongodb and can be found in the token repository (stored in db), but not 
for the tokens used on Google Authenticator app? Not sure if my 
understanding is correct?

Thanks in advance
Jeremy 

On Thursday, 21 February 2019 16:50:42 UTC+2, Mickaël wrote:
>
> Yes Jeremy, that's what I mean.
> I'm using JPA for my service registry and the CAS manager webapp but it is 
> the same way.
>
> For the second part, are you invited to enter your token code displayed by 
> your Google authenticator app?
>
> If it doesn't work, perhaps your server is not at the good time. NTP can 
> help you to fix it.
>
> Sincerely,
>
> Mickaël
>
> Le jeu. 21 févr. 2019 à 13:53, Jeremy Van Rooyen  > a écrit :
>
>> Hi Mickaël,
>>
>> On Thursday, 21 February 2019 14:01:17 UTC+2, Mickaël wrote:
>>>
>>> Hi Jeremy,
>>>
>>> It is a great news about the scratch codes.
>>>
>>> I'm not sure to understand your question about qrcode. To register a 
>>> device, it is possible and required when a service is registered on your 
>>> CAS with "Google Authentication" as MFA.
>>>
>>
>> Do you mean that the service "Google Authentication" as MFA must be 
>> registered under the services configuration in json format?
>>
>>  
>>
>>> So, at the first login without a registered device, user will be ask to 
>>> scan the qrcode on the screen and save (or print) the scratch codes. After 
>>> clilk on the next button, user should enter is token in the field to finish 
>>> the registration and be redirected to the service.
>>>
>>
>> This is what happens exactly the way you explain it here. So when I scan 
>> the qrcode with my phone it does not take the codes generated on the Google 
>> Authenticator app. It however does take the on screen codes.
>>
>> I hope this clears up my question?
>>
>>>
>>> Does it answer to your question Jeremy ?
>>>
>>> My own question about this system, how to unregistered a device in case 
>>> of change of device or loss ? I don't know URL to do that...
>>>
>>> Sincerely,
>>>
>>> Mickaël
>>>
>>> Le jeudi 21 février 2019 11:32:54 UTC+1, Jeremy Van Rooyen a écrit :

 Hi Mickaël,

 Thanks for your reply.

 So after playing around a bit more it seems like the on screen scratch 
 codes is being stored in the mongodb and using that it allows me to 
 authenticate perfectly.

 The next question is how would one register via the qrcode using the 
 Google Authenticator app on phone? Or am I not understanding something?

 Kind Regards
 Jeremy

 On Tuesday, 19 February 2019 10:30:29 UTC+2, Mickaël wrote:
>
> Hello,
>
> Are you sure there is anything register in your Mongo database ? 
> Scratch codes and token are store in DB for each user in 2 different 
> tables.
>
> It is strange to see that, normally "WHO" is the user, not the token :
> *WHO: 253227*
> *WHAT: Supplied credentials: [[token=253227]]*
>
> For information, I am using gauth with MariaDB without any issue.
>
> Mickaël
>
> Le jeudi 15 février 2018 09:53:52 UTC+1, Janina Byky a écrit :
>>
>> Hello,
>>
>> I'm trying to setup CAS 5.2.2 with Google Authenticator as second 
>> auth factor for specified services. CAS is running over LDAP (AD) and 
>> GAuth 
>> based on mongo. So far everything was great, build succeed, GAuth qrcode 
>> appears, user registers and now it's time for TOKEN form. I'm typing all 
>> scratch codes and those generated by Google Authenticator, but every 
>> single 
>> attempt is unsuccessful. Also there's no collection created to store 
>> tokens 
>> in mongo. Only GAuthRepository is created with proper values of 
>> registered 
>> users.
>>
>> *cas.properties*
>>
>> cas.authn.accept.users=
>>
>> cas.authn.ldap[0].order=0
>> cas.authn.ldap[0].type=AUTHENTICATED
>> cas.authn.ldap[0].ldapUrl={CUT}
>>

[cas-user] How to register a service in CAS while using SAM2.0 protocol

2019-02-21 Thread Pameliya Mukherjee

While I am hitting an endpoint like : 
"https://localhost:8443/cas/login?service=https://cas.example.org/cas/idp/profile/SAML2/Redirect/SSO=https://cas.org.example/cas/idp;

I am getting error like: 

2019-02-22 12:31:13,015 WARN 
[org.apereo.cas.web.flow.ServiceAuthorizationCheck] -<*Service Management: 
missing service. Service 
[https://cas.example.org/cas/idp/profile/SAML2/Redirect/SSO] is not found 
in service registry.>*
2019-02-22 12:31:13,017 WARN 
[org.apereo.cas.services.web.RegisteredServiceThemeResolver] - <*No 
registered service is found to match 
[AbstractWebApplicationService(id=https://cas.example.org/cas/idp/profile/SAML2/Redirect/SSO,
 
originalUrl=https://cas.example.org/cas/idp/profile/SAML2/Redirect/SSO, 
artifactId=null, principal=null, source=service, loggedOutAlready=false, 
format=XML, attributes={})] or access is denied. Using default theme 
[cas-theme-default]>*

*Please Help. I am new to this.*

-- 
- 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 cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/886fb227-7f84-46c3-a229-911fb749faaa%40apereo.org.

[cas-user] Custom encoder with cas 5.3

2019-02-21 Thread Ngô Hữu Tiến

How to custom encoderpassword with cas 5.3 ?
hepl me 

-- 
- 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 cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/aed7ce02-9330-4d9c-9eec-2a529fcab02a%40apereo.org.

[cas-user] Re: Cas Resources Link

2019-02-21 Thread Andy Ng

Awesome! A bit frustrated that enviornment.getProperties doesn't support 
list, but your implementation should be ok. Great work.

Cheers!
- Andy

-- 
- 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 cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/90ed9446-9e4b-41bb-aac8-b727fb563606%40apereo.org.

Re: [cas-user] DUO ByPass unenrolled users broken?

2019-02-21 Thread Richard Frovarp

Theoretically pre-auth follows the configuration of the integration. So if the
integration returns allow or bypass (been a while since I looked at it to
remember exact value), the CAS 5.2+ code won't trigger the Duo iframe to even
display. I can't remember if the CAS code was doing the pre-auth with or
without the IP. I think it was without.

The key thing is that the iframe will only ever return one value, the username
that passed Duo by one method or another. That method may be an actual method,
IP, remember me, or not registered with the integration letting them through.
If the user fails Duo, nothing is ever returned by the iframe. So if the iframe
is triggered (like it is in 5.1), and the user is allowed through by not being
enrolled and the integration configuration allowing it, then the iframe will
return the username back to the application. Since the only value is ever the
username, the application has no way of knowing if MFA was triggered or if the
user was bypassed. It's somewhat complicated. It took a decent amount of effort
on my part to get Duo to update their documentation to be a slight bit clearer.
They didn't see my issue as a security issue, so I need to get a better write
up about it out to the greater community.

The best method for bypassing is to have the IdP determine if Duo should be
applied, and only trigger Duo for the cases where it needs to be triggered, and
have Duo require MFA in all cases it is asked. This is more secure, and perhaps
more reliable. We were on Duo 1, which had weird outages that weren't fully
detected by various methods. So anyone that wasn't required to do Duo at NDSU,
never triggered a check to Duo that was failing, so they weren't even impacted.
For us to turn off Duo while Duo 1 was unresponsive, we only had to change the
group we were pointing at to something that didn't exist. Thus it would always
fail. There was the /ping endpoint, but during those outages it was always
reporting success.

On 2/21/19 1:19 PM, Travis Schmidt wrote:
All true, but I guess I am still confused by what Duo is doing. If pre-auth
just returns AUTH in all cases then what does it return for a bypassed user in
Duo from the Iframe? If it is a signed response then everything should be good
and CAS would assume the user was authenticated with Duo. Any other return
value I think would result in an authentication error and the user would not be
allowed to continue.

Travis

On Thu, Feb 21, 2019 at 11:02 AM Richard Frovarp
mailto:richard.frov...@ndsu.edu>> wrote:
5.1 uses a broken method for bypassing Duo. Or at least broken in some
respects. That's why you get the flash on the screen. 5.1 actually triggers the
widget, and the widget is doing the bypass. CAS doesn't know, so all of your
users under 5.1 are asserting via attribute release that they have performed
MFA, when in fact they may not have.

5.2+ added a method that makes an API call to see if the user can bypass. If
the user can bypass, they don't get the MFA iframe appearing. It also then
doesn't assert that MFA has happened when it hasn't.

What we're doing is that everyone that has to MFA is in an AD group. We use
that to trigger MFA. The Duo integration is configured to always require MFA,
because anyone sent to it will have been asserted by AD to require Duo. If you
need to bypass Duo, you just change the CAS config to point to an AD group that
doesn't exist, touch the file, and away it goes. Handy for when Duo is down, or
your own network is down.

On 2/21/19 11:38 AM, Travis Schmidt wrote:
Ok, That might explain it. Does the Duo iframe screen then flash by now for
these users when in the past it did not?

One way to get around possibly. If you have an attribute available that marks
a user has being enrolled in Duo, You can set a trigger to enforce Duo on only
those users, with name attribute values or groovy script. Trade off being is
that all services will require Duo for anyone enrolled in Duo, but you should
be able to set bypass flags in services or a bypass script. Depending on how
you are set up to use Duo now, this could be a big or small change.

Travis

On Thu, Feb 21, 2019 at 9:30 AM Greg Booth mailto:g...@mtu.edu>>
wrote:
We are seeing this issue as well, CAS 5.3.4 using MFA with Duo. We believe it
is an issue Duo has introduced with their new API. See the yellow box under
“User Account Status”:
https://apereo.github.io/cas/5.3.x/installation/DuoSecurity-Authentication.html#user-account-status

Rather than wait for Duo to fix this, we are looking into ways to bypass this
issue without disabling Duo entirely on our services, using Multifactor
Authentication Bypass:
https://apereo.github.io/cas/5.3.x/installation/Configuration-Properties-Common.html#multifactor-authentication-bypass

Have not gotten anywhere with this yet, if anyone has experience with those
config settings, we could use your help.

Greg

On Thu, Feb 21, 2019 at 9:39 AM atilling

Re: [cas-user] DUO ByPass unenrolled users broken?

2019-02-21 Thread Mailvaganam, Hari

https://community.duo.com/c/using-duo/release-notes

There isn’t anything in the Duo release notes for changes on 21st Feb….

We are on CAS5.3.4 – no impact so far – however if related to user-status, we 
check this upfront outside of Duo.

Best regards,

Hari Mailvaganam
Access Application Architect, Identity & Access Management (IAM)
Cybersecurity | CISO Office
The University of British Columbia | Musqueam Traditional Territory
420 - 6356 Agricultural Road | Vancouver BC | V6T1Z2 Canada
Phone 604 827 5117
Privacy Matters @ UBC

From:  on behalf of Travis Schmidt 

Reply-To: "cas-user@apereo.org" 
Date: Thursday, February 21, 2019 at 11:20 AM
To: CAS Community 
Subject: Re: [cas-user] DUO ByPass unenrolled users broken?

All true, but I guess I am still confused by what Duo is doing.  If pre-auth 
just returns AUTH in all cases then what does it return for a bypassed user in 
Duo from the Iframe?  If it is a signed response then everything should be good 
and CAS would assume the user was authenticated with Duo.  Any other return 
value I think would result in an authentication error and the user would not be 
allowed to continue.

Travis

On Thu, Feb 21, 2019 at 11:02 AM Richard Frovarp 
mailto:richard.frov...@ndsu.edu>> wrote:
5.1 uses a broken method for bypassing Duo. Or at least broken in some 
respects. That's why you get the flash on the screen. 5.1 actually triggers the 
widget, and the widget is doing the bypass. CAS doesn't know, so all of your 
users under 5.1 are asserting via attribute release that they have performed 
MFA, when in fact they may not have.

5.2+ added a method that makes an API call to see if the user can bypass. If 
the user can bypass, they don't get the MFA iframe appearing. It also then 
doesn't assert that MFA has happened when it hasn't.

What we're doing is that everyone that has to MFA is in an AD group. We use 
that to trigger MFA. The Duo integration is configured to always require MFA, 
because anyone sent to it will have been asserted by AD to require Duo. If you 
need to bypass Duo, you just change the CAS config to point to an AD group that 
doesn't exist, touch the file, and away it goes. Handy for when Duo is down, or 
your own network is down.

On 2/21/19 11:38 AM, Travis Schmidt wrote:
Ok, That might explain it.  Does the Duo iframe screen then flash by now for 
these users when in the past it did not?

One way to get around possibly.  If you have an attribute available that marks 
a user has being enrolled in Duo, You can set a trigger to enforce Duo on only 
those users, with name attribute values or groovy script.  Trade off being is 
that all services will require Duo for anyone enrolled in Duo, but you should 
be able to set bypass flags in services or a bypass script.  Depending on how 
you are set up to use Duo now, this could be a big or small change.

Travis

On Thu, Feb 21, 2019 at 9:30 AM Greg Booth mailto:g...@mtu.edu>> 
wrote:
We are seeing this issue as well, CAS 5.3.4 using MFA with Duo. We believe it 
is an issue Duo has introduced with their new API. See the yellow box under 
“User Account Status”: 
https://apereo.github.io/cas/5.3.x/installation/DuoSecurity-Authentication.html#user-account-status

Rather than wait for Duo to fix this, we are looking into ways to bypass this 
issue without disabling Duo entirely on our services, using Multifactor 
Authentication Bypass:
https://apereo.github.io/cas/5.3.x/installation/Configuration-Properties-Common.html#multifactor-authentication-bypass

Have not gotten anywhere with this yet, if anyone has experience with those 
config settings, we could use your help.

Greg

On Thu, Feb 21, 2019 at 9:39 AM atilling 
mailto:atill...@conncoll.edu>> wrote:
CAS version 5.1.9 using MFA with DUO. We had this working fine for about two 
years at this point. Tuesday it started causing problems for our unenrolled 
users. We have the DUO setting "allow unenrolled users to pass through without 
two-factor authentication" but sometime around 5 pm Tuesday all unenrolled 
users started getting the error "The validation request for ['ST-...'] cannot 
be satisfied. The request is either unrecognized or unfulfilled." whenever 
logging into a Duo protected service.

Has anyone else experienced this? Did something change with Duo in the last 72 
hours? We had to turn off Duo for these services and we don't want to keep it 
off.

Any help would be appreciated.
--
- 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 cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit

Re: [cas-user] DUO ByPass unenrolled users broken?

2019-02-21 Thread Travis Schmidt

All true, but I guess I am still confused by what Duo is doing.  If
pre-auth just returns AUTH in all cases then what does it return for a
bypassed user in Duo from the Iframe?  If it is a signed response then
everything should be good and CAS would assume the user was authenticated
with Duo.  Any other return value I think would result in an authentication
error and the user would not be allowed to continue.

Travis

On Thu, Feb 21, 2019 at 11:02 AM Richard Frovarp 
wrote:

> 5.1 uses a broken method for bypassing Duo. Or at least broken in some
> respects. That's why you get the flash on the screen. 5.1 actually triggers
> the widget, and the widget is doing the bypass. CAS doesn't know, so all of
> your users under 5.1 are asserting via attribute release that they have
> performed MFA, when in fact they may not have.
>
> 5.2+ added a method that makes an API call to see if the user can bypass.
> If the user can bypass, they don't get the MFA iframe appearing. It also
> then doesn't assert that MFA has happened when it hasn't.
>
> What we're doing is that everyone that has to MFA is in an AD group. We
> use that to trigger MFA. The Duo integration is configured to always
> require MFA, because anyone sent to it will have been asserted by AD to
> require Duo. If you need to bypass Duo, you just change the CAS config to
> point to an AD group that doesn't exist, touch the file, and away it goes.
> Handy for when Duo is down, or your own network is down.
>
> On 2/21/19 11:38 AM, Travis Schmidt wrote:
>
> Ok, That might explain it.  Does the Duo iframe screen then flash by now
> for these users when in the past it did not?
>
> One way to get around possibly.  If you have an attribute available that
> marks a user has being enrolled in Duo, You can set a trigger to enforce
> Duo on only those users, with name attribute values or groovy script.
> Trade off being is that all services will require Duo for anyone enrolled
> in Duo, but you should be able to set bypass flags in services or a bypass
> script.  Depending on how you are set up to use Duo now, this could be a
> big or small change.
>
> Travis
>
> On Thu, Feb 21, 2019 at 9:30 AM Greg Booth  wrote:
>
>> We are seeing this issue as well, CAS 5.3.4 using MFA with Duo. We
>> believe it is an issue Duo has introduced with their new API. See
>> the yellow box under “User Account Status”:
>> https://apereo.github.io/cas/5.3.x/installation/DuoSecurity-Authentication.html#user-account-status
>>
>> Rather than wait for Duo to fix this, we are looking into ways to bypass
>> this issue without disabling Duo entirely on our services, using
>> Multifactor Authentication Bypass:
>>
>> https://apereo.github.io/cas/5.3.x/installation/Configuration-Properties-Common.html#multifactor-authentication-bypass
>>
>> Have not gotten anywhere with this yet, if anyone has experience with
>> those config settings, we could use your help.
>>
>> Greg
>>
>> On Thu, Feb 21, 2019 at 9:39 AM atilling  wrote:
>>
>>> CAS version 5.1.9 using MFA with DUO. We had this working fine for about
>>> two years at this point. Tuesday it started causing problems for our
>>> unenrolled users. We have the DUO setting "allow unenrolled users to pass
>>> through without two-factor authentication" but sometime around 5 pm Tuesday
>>> all unenrolled users started getting the error "The validation request for
>>> ['ST-...'] cannot be satisfied. The request is either unrecognized or
>>> unfulfilled." whenever logging into a Duo protected service.
>>>
>>> Has anyone else experienced this? Did something change with Duo in the
>>> last 72 hours? We had to turn off Duo for these services and we don't want
>>> to keep it off.
>>>
>>> Any help would be appreciated.
>>> --
>>> - 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 cas-user+unsubscr...@apereo.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/apereo.org/d/msgid/cas-user/d6587944-0b2a-492c-9922-b84d0047486f%40apereo.org
>>> 
>>> .
>>>
>>
>>
>> --
>> Gregory Booth
>> Senior Systems Administrator & Technical Team Lead
>> IT Operations
>> Information Technology
>> Michigan Technological University
>> (906) 487-1797 <9064871797>
>> www.mtu.edu
>> www.it.mtu.edu
>> --
>> - 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

Re: [cas-user] DUO ByPass unenrolled users broken?

2019-02-21 Thread Richard Frovarp

5.1 uses a broken method for bypassing Duo. Or at least broken in some
respects. That's why you get the flash on the screen. 5.1 actually triggers the
widget, and the widget is doing the bypass. CAS doesn't know, so all of your
users under 5.1 are asserting via attribute release that they have performed
MFA, when in fact they may not have.

On 2/21/19 11:38 AM, Travis Schmidt wrote:
Ok, That might explain it. Does the Duo iframe screen then flash by now for
these users when in the past it did not?

Travis

Have not gotten anywhere with this yet, if anyone has experience with those
config settings, we could use your help.

Greg

On Thu, Feb 21, 2019 at 9:39 AM atilling
mailto:atill...@conncoll.edu>> wrote:
CAS version 5.1.9 using MFA with DUO. We had this working fine for about two
years at this point. Tuesday it started causing problems for our unenrolled
users. We have the DUO setting "allow unenrolled users to pass through without
two-factor authentication" but sometime around 5 pm Tuesday all unenrolled
users started getting the error "The validation request for ['ST-...'] cannot
be satisfied. The request is either unrecognized or unfulfilled." whenever
logging into a Duo protected service.

Has anyone else experienced this? Did something change with Duo in the last 72
hours? We had to turn off Duo for these services and we don't want to keep it
off.

Any help would be appreciated.
--
- 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 cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit
https://groups.google.com/a/apereo.org/d/msgid/cas-user/d6587944-0b2a-492c-9922-b84d0047486f%40apereo.org.

--
Gregory Booth
Senior Systems Administrator & Technical Team Lead
IT Operations
Information Technology
Michigan Technological University
(906) 487-1797
www.mtu.edu
www.it.mtu.edu
--
- 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 cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit
https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAH%2BQwmhzWZgfTVapQ--LXEcNnOLF-dwC%2B%3D6zSLAtnF0hSnN2Vw%40mail.gmail.com.
--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines:

Re: [cas-user] CAS-6.1.0-RC2 Invalid credentals

2019-02-21 Thread 'Robert Bond' via CAS Community

Hi Erik,

Can you provide an example of your AD config?

Here is an example of mine which is working on 6.1.0RC2:
## LDAP Settings ##
#
https://apereo.github.io/cas/development/configuration/Configuration-Properties-Common.html#ldap-connection-settings

### CONFIG for 6.1.0 RC2
cas.authn.ldap[0].type= AD
cas.authn.ldap[0].ldapUrl= ldap://ad.example.edu
cas.authn.ldap[0].baseDn= ou=All_Users,dc=example,dc=edu
cas.authn.ldap[0].searchFilter= cn={user}
cas.authn.ldap[0].bindDn= cn=aduser,ou=All_Users,dc=example,dc=edu
cas.authn.ldap[0].bindCredential= examplePassword!
cas.authn.ldap[0].dnFormat= cn=%s,ou=All_Users,dc=example,dc=edu
cas.authn.ldap[0].useSsl= false
cas.authn.ldap[0].name= Example-Active-Directory
cas.authn.ldap[0].principalAttributeList
=cn:commonName,sn:surname,displayName:displayName,mail:email,givenName,memberOf,samAccountName:eduPersonPrincipalName,mail:emailAddress


On Fri, Feb 8, 2019 at 4:40 PM Erik Mallory  wrote:

> Hello,
>
> I’m getting  the following error trying to authenticate.
>
> I’m using AD for password storage. I this did work in RC1 I’m at a loss as
> to what might be broken. Any  help would be greatly apricated.
>
> 2019-02-08 16:30:35,551 DEBUG
> [org.apereo.cas.authentication.support.DefaultLdapAccountStateHandler] -
> 
>
> 2019-02-08 16:30:35,551 ERROR
> [org.apereo.cas.authentication.PolicyBasedAuthenticationManager] -
>  authentication handler that supports
> [UsernamePasswordCredential(username=f282c439, source=null)] of type
> [UsernamePasswordCredential]. Examine the configuration to ensure a method
> of authentication is defined and analyze CAS logs at DEBUG level to trace
> the authentication event.>
>
> 2019-02-08 16:30:35,552 DEBUG
> [org.apereo.cas.authentication.PolicyBasedAuthenticationManager] - <[WSUAD]
> exception details: [Invalid credentials].>
>
> 2019-02-08 16:30:35,552 DEBUG
> [org.apereo.cas.authentication.PolicyBasedAuthenticationManager] -
>  [UsernamePasswordCredential(username=f282c439, source=null)]. Trying
> next...>
>
>
>
>
>
> 2019-02-08 16:30:35,568 DEBUG
> [org.apereo.cas.web.flow.resolver.impl.DefaultCasDelegatingWebflowEventResolver]
> - <1 errors, 0 successes>
>
> org.apereo.cas.authentication.AuthenticationException: 1 errors, 0
> successes
>
>at
> org.apereo.cas.authentication.PolicyBasedAuthenticationManager.evaluateFinalAuthentication(PolicyBasedAuthenticationManager.java:349)
> ~[cas-server-core-authentication-api-6.1.0-RC2-SNAPSHOT.jar:6.1.0-RC2-SNAPSHOT]
>
>at
> org.apereo.cas.authentication.PolicyBasedAuthenticationManager.authenticateInternal(PolicyBasedAuthenticationManager.java:327)
> ~[cas-server-core-authentication-api-6.1.0-RC2-SNAPSHOT.jar:6.1.0-RC2-SNAPSHOT]
>
>at
> org.apereo.cas.authentication.PolicyBasedAuthenticationManager.authenticate(PolicyBasedAuthenticationManager.java:136)
> ~[cas-server-core-authentication-api-6.1.0-RC2-SNAPSHOT.jar:6.1.0-RC2-SNAPSHOT]
>
>at
> org.apereo.cas.authentication.PolicyBasedAuthenticationManager$$FastClassBySpringCGLIB$$90e801d3.invoke()
> ~[cas-server-core-authentication-api-6.1.0-RC2-SNAPSHOT.jar:6.1.0-RC2-SNAPSHOT]
>
>at
> org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
> ~[spring-core-5.1.4.RELEASE.jar:5.1.4.RELEASE]
>
>at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:749)
> ~[spring-aop-5.1.4.RELEASE.jar:5.1.4.RELEASE]
>
>at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
> ~[spring-aop-5.1.4.RELEASE.jar:5.1.4.RELEASE]
>
>at
> org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:88)
> ~[spring-aop-5.1.4.RELEASE.jar:5.1.4.RELEASE]
>
>at
> org.apereo.inspektr.audit.AuditTrailManagementAspect.handleAuditTrail(AuditTrailManagementAspect.java:135)
> ~[inspektr-audit-1.8.4.GA.jar:1.8.4.GA]
>
>at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) ~[?:?]
>
>at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:?]
>
>at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:?]
>
>at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
>
>at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:644)
> ~[spring-aop-5.1.4.RELEASE.jar:5.1.4.RELEASE]
>
>at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:633)
> ~[spring-aop-5.1.4.RELEASE.jar:5.1.4.RELEASE]
>
>at
> org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:70)
> ~[spring-aop-5.1.4.RELEASE.jar:5.1.4.RELEASE]
>
>at
>

Re: [cas-user] DUO ByPass unenrolled users broken?

2019-02-21 Thread Travis Schmidt

Ok, That might explain it.  Does the Duo iframe screen then flash by now
for these users when in the past it did not?

One way to get around possibly.  If you have an attribute available that
marks a user has being enrolled in Duo, You can set a trigger to enforce
Duo on only those users, with name attribute values or groovy script.
Trade off being is that all services will require Duo for anyone enrolled
in Duo, but you should be able to set bypass flags in services or a bypass
script.  Depending on how you are set up to use Duo now, this could be a
big or small change.

Travis

On Thu, Feb 21, 2019 at 9:30 AM Greg Booth  wrote:

> We are seeing this issue as well, CAS 5.3.4 using MFA with Duo. We believe
> it is an issue Duo has introduced with their new API. See the yellow box
> under “User Account Status”:
> https://apereo.github.io/cas/5.3.x/installation/DuoSecurity-Authentication.html#user-account-status
>
> Rather than wait for Duo to fix this, we are looking into ways to bypass
> this issue without disabling Duo entirely on our services, using
> Multifactor Authentication Bypass:
>
> https://apereo.github.io/cas/5.3.x/installation/Configuration-Properties-Common.html#multifactor-authentication-bypass
>
> Have not gotten anywhere with this yet, if anyone has experience with
> those config settings, we could use your help.
>
> Greg
>
> On Thu, Feb 21, 2019 at 9:39 AM atilling  wrote:
>
>> CAS version 5.1.9 using MFA with DUO. We had this working fine for about
>> two years at this point. Tuesday it started causing problems for our
>> unenrolled users. We have the DUO setting "allow unenrolled users to pass
>> through without two-factor authentication" but sometime around 5 pm Tuesday
>> all unenrolled users started getting the error "The validation request for
>> ['ST-...'] cannot be satisfied. The request is either unrecognized or
>> unfulfilled." whenever logging into a Duo protected service.
>>
>> Has anyone else experienced this? Did something change with Duo in the
>> last 72 hours? We had to turn off Duo for these services and we don't want
>> to keep it off.
>>
>> Any help would be appreciated.
>>
>> --
>> - 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 cas-user+unsubscr...@apereo.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/apereo.org/d/msgid/cas-user/d6587944-0b2a-492c-9922-b84d0047486f%40apereo.org
>> 
>> .
>>
>
>
> --
> Gregory Booth
> Senior Systems Administrator & Technical Team Lead
> IT Operations
> Information Technology
> Michigan Technological University
> (906) 487-1797 <9064871797>
> www.mtu.edu
> www.it.mtu.edu
>
> --
> - 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 cas-user+unsubscr...@apereo.org.
> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAH%2BQwmhzWZgfTVapQ--LXEcNnOLF-dwC%2B%3D6zSLAtnF0hSnN2Vw%40mail.gmail.com
> 
> .
>

-- 
- 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 cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAC_RtEbNSJGZZkr-knNrb5kDUcRda6BBDY_KRqDEsXnSz6nMrw%40mail.gmail.com.

Re: [cas-user] DUO ByPass unenrolled users broken?

2019-02-21 Thread Greg Booth

We are seeing this issue as well, CAS 5.3.4 using MFA with Duo. We believe
it is an issue Duo has introduced with their new API. See the yellow box
under “User Account Status”:
https://apereo.github.io/cas/5.3.x/installation/DuoSecurity-Authentication.html#user-account-status

Rather than wait for Duo to fix this, we are looking into ways to bypass
this issue without disabling Duo entirely on our services, using
Multifactor Authentication Bypass:
https://apereo.github.io/cas/5.3.x/installation/Configuration-Properties-Common.html#multifactor-authentication-bypass

Have not gotten anywhere with this yet, if anyone has experience with those
config settings, we could use your help.

Greg

On Thu, Feb 21, 2019 at 9:39 AM atilling  wrote:

> CAS version 5.1.9 using MFA with DUO. We had this working fine for about
> two years at this point. Tuesday it started causing problems for our
> unenrolled users. We have the DUO setting "allow unenrolled users to pass
> through without two-factor authentication" but sometime around 5 pm Tuesday
> all unenrolled users started getting the error "The validation request for
> ['ST-...'] cannot be satisfied. The request is either unrecognized or
> unfulfilled." whenever logging into a Duo protected service.
>
> Has anyone else experienced this? Did something change with Duo in the
> last 72 hours? We had to turn off Duo for these services and we don't want
> to keep it off.
>
> Any help would be appreciated.
>
> --
> - 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 cas-user+unsubscr...@apereo.org.
> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-user/d6587944-0b2a-492c-9922-b84d0047486f%40apereo.org
> 
> .
>


-- 
Gregory Booth
Senior Systems Administrator & Technical Team Lead
IT Operations
Information Technology
Michigan Technological University
(906) 487-1797 <9064871797>
www.mtu.edu
www.it.mtu.edu

-- 
- 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 cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAH%2BQwmhzWZgfTVapQ--LXEcNnOLF-dwC%2B%3D6zSLAtnF0hSnN2Vw%40mail.gmail.com.

Re: [cas-user] DUO ByPass unenrolled users broken?

2019-02-21 Thread Travis Schmidt

Nothing has recently changed in your CAS Config?

If you can set this class to debug logging level
org.apereo.cas.authentication.DefaultAuthenticationContextValidator.
That should give you some insight into perhaps why this is getting hit.

On Thu, Feb 21, 2019 at 6:39 AM atilling  wrote:

> CAS version 5.1.9 using MFA with DUO. We had this working fine for about
> two years at this point. Tuesday it started causing problems for our
> unenrolled users. We have the DUO setting "allow unenrolled users to pass
> through without two-factor authentication" but sometime around 5 pm Tuesday
> all unenrolled users started getting the error "The validation request for
> ['ST-...'] cannot be satisfied. The request is either unrecognized or
> unfulfilled." whenever logging into a Duo protected service.
>
> Has anyone else experienced this? Did something change with Duo in the
> last 72 hours? We had to turn off Duo for these services and we don't want
> to keep it off.
>
> Any help would be appreciated.
>
> --
> - 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 cas-user+unsubscr...@apereo.org.
> To view this discussion on the web visit
> https://groups.google.com/a/apereo.org/d/msgid/cas-user/d6587944-0b2a-492c-9922-b84d0047486f%40apereo.org
> 
> .
>

-- 
- 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 cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAC_RtEYTpXOq15rrdGyJABxGjoYGjyu%3DKqw4fP3KVFgE%3Dq4_CA%40mail.gmail.com.

Re: [cas-user] Re: CAS 5.2.2 with MFA using Google Authenticator / GAuth

2019-02-21 Thread Mickaël

Yes Jeremy, that's what I mean.
I'm using JPA for my service registry and the CAS manager webapp but it is
the same way.

For the second part, are you invited to enter your token code displayed by
your Google authenticator app?

If it doesn't work, perhaps your server is not at the good time. NTP can
help you to fix it.

Sincerely,

Mickaël

Le jeu. 21 févr. 2019 à 13:53, Jeremy Van Rooyen  a
écrit :

> Hi Mickaël,
>
> On Thursday, 21 February 2019 14:01:17 UTC+2, Mickaël wrote:
>>
>> Hi Jeremy,
>>
>> It is a great news about the scratch codes.
>>
>> I'm not sure to understand your question about qrcode. To register a
>> device, it is possible and required when a service is registered on your
>> CAS with "Google Authentication" as MFA.
>>
>
> Do you mean that the service "Google Authentication" as MFA must be
> registered under the services configuration in json format?
>
>
>
>> So, at the first login without a registered device, user will be ask to
>> scan the qrcode on the screen and save (or print) the scratch codes. After
>> clilk on the next button, user should enter is token in the field to finish
>> the registration and be redirected to the service.
>>
>
> This is what happens exactly the way you explain it here. So when I scan
> the qrcode with my phone it does not take the codes generated on the Google
> Authenticator app. It however does take the on screen codes.
>
> I hope this clears up my question?
>
>>
>> Does it answer to your question Jeremy ?
>>
>> My own question about this system, how to unregistered a device in case
>> of change of device or loss ? I don't know URL to do that...
>>
>> Sincerely,
>>
>> Mickaël
>>
>> Le jeudi 21 février 2019 11:32:54 UTC+1, Jeremy Van Rooyen a écrit :
>>>
>>> Hi Mickaël,
>>>
>>> Thanks for your reply.
>>>
>>> So after playing around a bit more it seems like the on screen scratch
>>> codes is being stored in the mongodb and using that it allows me to
>>> authenticate perfectly.
>>>
>>> The next question is how would one register via the qrcode using the
>>> Google Authenticator app on phone? Or am I not understanding something?
>>>
>>> Kind Regards
>>> Jeremy
>>>
>>> On Tuesday, 19 February 2019 10:30:29 UTC+2, Mickaël wrote:

 Hello,

 Are you sure there is anything register in your Mongo database ?
 Scratch codes and token are store in DB for each user in 2 different 
 tables.

 It is strange to see that, normally "WHO" is the user, not the token :
 *WHO: 253227*
 *WHAT: Supplied credentials: [[token=253227]]*

 For information, I am using gauth with MariaDB without any issue.

 Mickaël

 Le jeudi 15 février 2018 09:53:52 UTC+1, Janina Byky a écrit :
>
> Hello,
>
> I'm trying to setup CAS 5.2.2 with Google Authenticator as second auth
> factor for specified services. CAS is running over LDAP (AD) and GAuth
> based on mongo. So far everything was great, build succeed, GAuth qrcode
> appears, user registers and now it's time for TOKEN form. I'm typing all
> scratch codes and those generated by Google Authenticator, but every 
> single
> attempt is unsuccessful. Also there's no collection created to store 
> tokens
> in mongo. Only GAuthRepository is created with proper values of registered
> users.
>
> *cas.properties*
>
> cas.authn.accept.users=
>
> cas.authn.ldap[0].order=0
> cas.authn.ldap[0].type=AUTHENTICATED
> cas.authn.ldap[0].ldapUrl={CUT}
> cas.authn.ldap[0].connectionStrategy=DEFAULT
> cas.authn.ldap[0].useSsl=true
> cas.authn.ldap[0].connectTimeout=15000
> cas.authn.ldap[0].subtreeSearch=true
> cas.authn.ldap[0].baseDn={CUT}
>
> cas.authn.ldap[0].userFilter=(|(sAMAccountName={user})(userPrincipalName={user}))
> cas.authn.ldap[0].bindDn={CUT}
> cas.authn.ldap[0].bindCredential={CUT}
> cas.authn.ldap[0].enhanceWithEntryResolver=true
> cas.authn.ldap[0].principalAttributeId=sAMAccountName
> cas.authn.ldap[0].principalAttributePassword=
> cas.authn.ldap[0].usePasswordPolicy=true
>
> cas.authn.ldap[0].principalAttributeList=sn,cn:commonName,givenName,sAMAccountName,memberOf
> cas.authn.ldap[0].allowMultiplePrincipalAttributeValues=true
> cas.authn.ldap[0].poolPassivator=NONE
> cas.authn.ldap[0].minPoolSize=2
> cas.authn.ldap[0].maxPoolSize=15
>
>
> cas.authn.mfa.globalProviderId=mfa-gauth
> cas.authn.mfa.globalFailureMode=CLOSED
>
> cas.authn.mfa.gauth.issuer=TEST
> cas.authn.mfa.gauth.codeDigits=6
> cas.authn.mfa.gauth.timeStepSize=60
> cas.authn.mfa.gauth.windowSize=3
> cas.authn.mfa.gauth.label=TEST
> cas.authn.mfa.gauth.rank=0
>
> cas.authn.mfa.gauth.cleaner.enabled=true
> cas.authn.mfa.gauth.cleaner.schedule.startDelay=2
> cas.authn.mfa.gauth.cleaner.schedule.repeatInterval=6
>
> cas.authn.mfa.gauth.bypass.type=DEFAULT
>
>

[cas-user] DUO ByPass unenrolled users broken?

2019-02-21 Thread atilling

CAS version 5.1.9 using MFA with DUO. We had this working fine for about 
two years at this point. Tuesday it started causing problems for our 
unenrolled users. We have the DUO setting "allow unenrolled users to pass 
through without two-factor authentication" but sometime around 5 pm Tuesday 
all unenrolled users started getting the error "The validation request for 
['ST-...'] cannot be satisfied. The request is either unrecognized or 
unfulfilled." whenever logging into a Duo protected service.

Has anyone else experienced this? Did something change with Duo in the last 
72 hours? We had to turn off Duo for these services and we don't want to 
keep it off.

Any help would be appreciated. 

-- 
- 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 cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/d6587944-0b2a-492c-9922-b84d0047486f%40apereo.org.

[cas-user] Re: Cas Resources Link

2019-02-21 Thread Rodrigo Siqueira

Hey, I've got it working now. 
Here's what I've did to get it working:  

Created the following configuration to expose a bean for my properties:

@Configuration
public class MyConfiguration {
@Bean
public MyConfigurationProperties myConfigurationProperties(){
return new MyConfigurationProperties();
}
}


Created a class that represents my properties:

@Getter
@Setter
@ConfigurationProperties(value = "my", ignoreUnknownFields = false)
public class MyConfigurationProperties {

@NestedConfigurationProperty
private MySystemProperties system = new MySystemProperties();

private List resources = new ArrayList<>();

}


@Getter
@Setter
public class MvSystemProperties implements Serializable {
private String name;
private String version;
}



my:
  system:
name: SystemName
version: 1.0.0
  resources:
- name: cas.login.resources.res1 #Translatable tag in Thymeleaf using 
#{${}}
  url: /res1
- name: Sample #If tag does not exists in messageSource it just puts 
the text as-is (kinda useful)
  url: /sample


META-INF/spring.factories

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
  org.apereo.cas.config.CasEmbeddedContainerTomcatConfiguration,\
  org.apereo.cas.config.CasEmbeddedContainerTomcatFiltersConfiguration,\
  br.com.my.sso.properties.MyConfiguration



Thanks again for your help!



-- 
- 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 cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/41eea141-ad89-4424-aff5-bc003d70b1b2%40apereo.org.

[cas-user] Re: CAS-6.1.0-RC2 Invalid credentals

2019-02-21 Thread Fabien Tréguer

Hello Erik,

have you fixed your issue? I've the same problem using passwordless 
authentication.

I think I'm missing something, configuration or else.

Thank you.

Fabien

Le vendredi 8 février 2019 23:40:37 UTC+1, Erik Mallory a écrit :
>
> Hello,
>
> I’m getting  the following error trying to authenticate. 
>
> I’m using AD for password storage. I this did work in RC1 I’m at a loss as 
> to what might be broken. Any  help would be greatly apricated. 
>
> 2019-02-08 16:30:35,551 DEBUG 
> [org.apereo.cas.authentication.support.DefaultLdapAccountStateHandler] - 
> 
>
> 2019-02-08 16:30:35,551 ERROR 
> [org.apereo.cas.authentication.PolicyBasedAuthenticationManager] - 
>  authentication handler that supports 
> [UsernamePasswordCredential(username=f282c439, source=null)] of type 
> [UsernamePasswordCredential]. Examine the configuration to ensure a method 
> of authentication is defined and analyze CAS logs at DEBUG level to trace 
> the authentication event.>
>
> 2019-02-08 16:30:35,552 DEBUG 
> [org.apereo.cas.authentication.PolicyBasedAuthenticationManager] - <[WSUAD] 
> exception details: [Invalid credentials].>
>
> 2019-02-08 16:30:35,552 DEBUG 
> [org.apereo.cas.authentication.PolicyBasedAuthenticationManager] - 
>  [UsernamePasswordCredential(username=f282c439, source=null)]. Trying 
> next...>
>
>  
>
>  
>
> 2019-02-08 16:30:35,568 DEBUG 
> [org.apereo.cas.web.flow.resolver.impl.DefaultCasDelegatingWebflowEventResolver]
>  
> - <1 errors, 0 successes>
>
> org.apereo.cas.authentication.AuthenticationException: 1 errors, 0 
> successes
>
>at 
> org.apereo.cas.authentication.PolicyBasedAuthenticationManager.evaluateFinalAuthentication(PolicyBasedAuthenticationManager.java:349)
>  
> ~[cas-server-core-authentication-api-6.1.0-RC2-SNAPSHOT.jar:6.1.0-RC2-SNAPSHOT]
>
>at 
> org.apereo.cas.authentication.PolicyBasedAuthenticationManager.authenticateInternal(PolicyBasedAuthenticationManager.java:327)
>  
> ~[cas-server-core-authentication-api-6.1.0-RC2-SNAPSHOT.jar:6.1.0-RC2-SNAPSHOT]
>
>at 
> org.apereo.cas.authentication.PolicyBasedAuthenticationManager.authenticate(PolicyBasedAuthenticationManager.java:136)
>  
> ~[cas-server-core-authentication-api-6.1.0-RC2-SNAPSHOT.jar:6.1.0-RC2-SNAPSHOT]
>
>at 
> org.apereo.cas.authentication.PolicyBasedAuthenticationManager$$FastClassBySpringCGLIB$$90e801d3.invoke()
>  
> ~[cas-server-core-authentication-api-6.1.0-RC2-SNAPSHOT.jar:6.1.0-RC2-SNAPSHOT]
>
>at 
> org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218) 
> ~[spring-core-5.1.4.RELEASE.jar:5.1.4.RELEASE]
>
>at 
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:749)
>  
> ~[spring-aop-5.1.4.RELEASE.jar:5.1.4.RELEASE]
>
>at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
>  
> ~[spring-aop-5.1.4.RELEASE.jar:5.1.4.RELEASE]
>
>at 
> org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:88)
>  
> ~[spring-aop-5.1.4.RELEASE.jar:5.1.4.RELEASE]
>
>at 
> org.apereo.inspektr.audit.AuditTrailManagementAspect.handleAuditTrail(AuditTrailManagementAspect.java:135)
>  
> ~[inspektr-audit-1.8.4.GA.jar:1.8.4.GA]
>
>at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method) ~[?:?]
>
>at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>  
> ~[?:?]
>
>at 
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  
> ~[?:?]
>
>at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
>
>at 
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:644)
>  
> ~[spring-aop-5.1.4.RELEASE.jar:5.1.4.RELEASE]
>
>at 
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:633)
>  
> ~[spring-aop-5.1.4.RELEASE.jar:5.1.4.RELEASE]
>
>at 
> org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:70)
>  
> ~[spring-aop-5.1.4.RELEASE.jar:5.1.4.RELEASE]
>
>at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:175)
>  
> ~[spring-aop-5.1.4.RELEASE.jar:5.1.4.RELEASE]
>
>at 
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:93)
>  
> ~[spring-aop-5.1.4.RELEASE.jar:5.1.4.RELEASE]
>
>at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
>  
> ~[spring-aop-5.1.4.RELEASE.jar:5.1.4.RELEASE]
>
>at 
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:688)
>  
> ~[spring-aop-5.1.4.RELEASE.jar:5.1.4.RELEASE]
>
>at 
>

[cas-user] Re: CAS 5.2.2 with MFA using Google Authenticator / GAuth

2019-02-21 Thread Jeremy Van Rooyen

Hi Mickaël,

On Thursday, 21 February 2019 14:01:17 UTC+2, Mickaël wrote:
>
> Hi Jeremy,
>
> It is a great news about the scratch codes.
>
> I'm not sure to understand your question about qrcode. To register a 
> device, it is possible and required when a service is registered on your 
> CAS with "Google Authentication" as MFA.
>

Do you mean that the service "Google Authentication" as MFA must be 
registered under the services configuration in json format?

 

> So, at the first login without a registered device, user will be ask to 
> scan the qrcode on the screen and save (or print) the scratch codes. After 
> clilk on the next button, user should enter is token in the field to finish 
> the registration and be redirected to the service.
>

This is what happens exactly the way you explain it here. So when I scan 
the qrcode with my phone it does not take the codes generated on the Google 
Authenticator app. It however does take the on screen codes.

I hope this clears up my question?

>
> Does it answer to your question Jeremy ?
>
> My own question about this system, how to unregistered a device in case of 
> change of device or loss ? I don't know URL to do that...
>
> Sincerely,
>
> Mickaël
>
> Le jeudi 21 février 2019 11:32:54 UTC+1, Jeremy Van Rooyen a écrit :
>>
>> Hi Mickaël,
>>
>> Thanks for your reply.
>>
>> So after playing around a bit more it seems like the on screen scratch 
>> codes is being stored in the mongodb and using that it allows me to 
>> authenticate perfectly.
>>
>> The next question is how would one register via the qrcode using the 
>> Google Authenticator app on phone? Or am I not understanding something?
>>
>> Kind Regards
>> Jeremy
>>
>> On Tuesday, 19 February 2019 10:30:29 UTC+2, Mickaël wrote:
>>>
>>> Hello,
>>>
>>> Are you sure there is anything register in your Mongo database ? Scratch 
>>> codes and token are store in DB for each user in 2 different tables.
>>>
>>> It is strange to see that, normally "WHO" is the user, not the token :
>>> *WHO: 253227*
>>> *WHAT: Supplied credentials: [[token=253227]]*
>>>
>>> For information, I am using gauth with MariaDB without any issue.
>>>
>>> Mickaël
>>>
>>> Le jeudi 15 février 2018 09:53:52 UTC+1, Janina Byky a écrit :

 Hello,

 I'm trying to setup CAS 5.2.2 with Google Authenticator as second auth 
 factor for specified services. CAS is running over LDAP (AD) and GAuth 
 based on mongo. So far everything was great, build succeed, GAuth qrcode 
 appears, user registers and now it's time for TOKEN form. I'm typing all 
 scratch codes and those generated by Google Authenticator, but every 
 single 
 attempt is unsuccessful. Also there's no collection created to store 
 tokens 
 in mongo. Only GAuthRepository is created with proper values of registered 
 users.

 *cas.properties*

 cas.authn.accept.users=

 cas.authn.ldap[0].order=0
 cas.authn.ldap[0].type=AUTHENTICATED
 cas.authn.ldap[0].ldapUrl={CUT}
 cas.authn.ldap[0].connectionStrategy=DEFAULT
 cas.authn.ldap[0].useSsl=true
 cas.authn.ldap[0].connectTimeout=15000
 cas.authn.ldap[0].subtreeSearch=true
 cas.authn.ldap[0].baseDn={CUT}

 cas.authn.ldap[0].userFilter=(|(sAMAccountName={user})(userPrincipalName={user}))
 cas.authn.ldap[0].bindDn={CUT}
 cas.authn.ldap[0].bindCredential={CUT}
 cas.authn.ldap[0].enhanceWithEntryResolver=true
 cas.authn.ldap[0].principalAttributeId=sAMAccountName
 cas.authn.ldap[0].principalAttributePassword=
 cas.authn.ldap[0].usePasswordPolicy=true

 cas.authn.ldap[0].principalAttributeList=sn,cn:commonName,givenName,sAMAccountName,memberOf
 cas.authn.ldap[0].allowMultiplePrincipalAttributeValues=true
 cas.authn.ldap[0].poolPassivator=NONE
 cas.authn.ldap[0].minPoolSize=2
 cas.authn.ldap[0].maxPoolSize=15


 cas.authn.mfa.globalProviderId=mfa-gauth
 cas.authn.mfa.globalFailureMode=CLOSED

 cas.authn.mfa.gauth.issuer=TEST
 cas.authn.mfa.gauth.codeDigits=6
 cas.authn.mfa.gauth.timeStepSize=60
 cas.authn.mfa.gauth.windowSize=3
 cas.authn.mfa.gauth.label=TEST
 cas.authn.mfa.gauth.rank=0

 cas.authn.mfa.gauth.cleaner.enabled=true
 cas.authn.mfa.gauth.cleaner.schedule.startDelay=2
 cas.authn.mfa.gauth.cleaner.schedule.repeatInterval=6

 cas.authn.mfa.gauth.bypass.type=DEFAULT

 cas.authn.mfa.gauth.mongo.clientUri=${mongo.uri}
 cas.authn.mfa.gauth.mongo.dropCollection=false
 cas.authn.mfa.gauth.mongo.collection=GAuthRepository

 cas.authn.mfa.gauth.mongo.tokenCollection=GoogleAuthenticatorMongoDbTokenRepository



 *pom.xml*

 
 org.apereo.cas
 cas-server-webapp${app.server}
 ${cas.version}
 war
 runtime
 
 
 org.apereo.cas

[cas-user] Re: CAS 5.2.2 with MFA using Google Authenticator / GAuth

2019-02-21 Thread Mickaël

Hi Jeremy,

It is a great news about the scratch codes.

I'm not sure to understand your question about qrcode. To register a 
device, it is possible and required when a service is registered on your 
CAS with "Google Authentication" as MFA.
So, at the first login without a registered device, user will be ask to 
scan the qrcode on the screen and save (or print) the scratch codes. After 
clilk on the next button, user should enter is token in the field to finish 
the registration and be redirected to the service.

Does it answer to your question Jeremy ?

My own question about this system, how to unregistered a device in case of 
change of device or loss ? I don't know URL to do that...

Sincerely,

Mickaël

Le jeudi 21 février 2019 11:32:54 UTC+1, Jeremy Van Rooyen a écrit :
>
> Hi Mickaël,
>
> Thanks for your reply.
>
> So after playing around a bit more it seems like the on screen scratch 
> codes is being stored in the mongodb and using that it allows me to 
> authenticate perfectly.
>
> The next question is how would one register via the qrcode using the 
> Google Authenticator app on phone? Or am I not understanding something?
>
> Kind Regards
> Jeremy
>
> On Tuesday, 19 February 2019 10:30:29 UTC+2, Mickaël wrote:
>>
>> Hello,
>>
>> Are you sure there is anything register in your Mongo database ? Scratch 
>> codes and token are store in DB for each user in 2 different tables.
>>
>> It is strange to see that, normally "WHO" is the user, not the token :
>> *WHO: 253227*
>> *WHAT: Supplied credentials: [[token=253227]]*
>>
>> For information, I am using gauth with MariaDB without any issue.
>>
>> Mickaël
>>
>> Le jeudi 15 février 2018 09:53:52 UTC+1, Janina Byky a écrit :
>>>
>>> Hello,
>>>
>>> I'm trying to setup CAS 5.2.2 with Google Authenticator as second auth 
>>> factor for specified services. CAS is running over LDAP (AD) and GAuth 
>>> based on mongo. So far everything was great, build succeed, GAuth qrcode 
>>> appears, user registers and now it's time for TOKEN form. I'm typing all 
>>> scratch codes and those generated by Google Authenticator, but every single 
>>> attempt is unsuccessful. Also there's no collection created to store tokens 
>>> in mongo. Only GAuthRepository is created with proper values of registered 
>>> users.
>>>
>>> *cas.properties*
>>>
>>> cas.authn.accept.users=
>>>
>>> cas.authn.ldap[0].order=0
>>> cas.authn.ldap[0].type=AUTHENTICATED
>>> cas.authn.ldap[0].ldapUrl={CUT}
>>> cas.authn.ldap[0].connectionStrategy=DEFAULT
>>> cas.authn.ldap[0].useSsl=true
>>> cas.authn.ldap[0].connectTimeout=15000
>>> cas.authn.ldap[0].subtreeSearch=true
>>> cas.authn.ldap[0].baseDn={CUT}
>>>
>>> cas.authn.ldap[0].userFilter=(|(sAMAccountName={user})(userPrincipalName={user}))
>>> cas.authn.ldap[0].bindDn={CUT}
>>> cas.authn.ldap[0].bindCredential={CUT}
>>> cas.authn.ldap[0].enhanceWithEntryResolver=true
>>> cas.authn.ldap[0].principalAttributeId=sAMAccountName
>>> cas.authn.ldap[0].principalAttributePassword=
>>> cas.authn.ldap[0].usePasswordPolicy=true
>>>
>>> cas.authn.ldap[0].principalAttributeList=sn,cn:commonName,givenName,sAMAccountName,memberOf
>>> cas.authn.ldap[0].allowMultiplePrincipalAttributeValues=true
>>> cas.authn.ldap[0].poolPassivator=NONE
>>> cas.authn.ldap[0].minPoolSize=2
>>> cas.authn.ldap[0].maxPoolSize=15
>>>
>>>
>>> cas.authn.mfa.globalProviderId=mfa-gauth
>>> cas.authn.mfa.globalFailureMode=CLOSED
>>>
>>> cas.authn.mfa.gauth.issuer=TEST
>>> cas.authn.mfa.gauth.codeDigits=6
>>> cas.authn.mfa.gauth.timeStepSize=60
>>> cas.authn.mfa.gauth.windowSize=3
>>> cas.authn.mfa.gauth.label=TEST
>>> cas.authn.mfa.gauth.rank=0
>>>
>>> cas.authn.mfa.gauth.cleaner.enabled=true
>>> cas.authn.mfa.gauth.cleaner.schedule.startDelay=2
>>> cas.authn.mfa.gauth.cleaner.schedule.repeatInterval=6
>>>
>>> cas.authn.mfa.gauth.bypass.type=DEFAULT
>>>
>>> cas.authn.mfa.gauth.mongo.clientUri=${mongo.uri}
>>> cas.authn.mfa.gauth.mongo.dropCollection=false
>>> cas.authn.mfa.gauth.mongo.collection=GAuthRepository
>>>
>>> cas.authn.mfa.gauth.mongo.tokenCollection=GoogleAuthenticatorMongoDbTokenRepository
>>>
>>>
>>>
>>> *pom.xml*
>>>
>>> 
>>> org.apereo.cas
>>> cas-server-webapp${app.server}
>>> ${cas.version}
>>> war
>>> runtime
>>> 
>>> 
>>> org.apereo.cas
>>> cas-server-support-ldap
>>> ${cas.version}
>>> 
>>> 
>>> org.apereo.cas
>>> cas-server-support-saml
>>> ${cas.version}
>>> 
>>> 
>>> org.apereo.cas
>>> cas-server-support-gauth
>>> ${cas.version}
>>> 
>>> 
>>> org.apereo.cas
>>> cas-server-support-gauth-mongo
>>> ${cas.version}
>>> 
>>>
>>>
>>> *catalina.log*
>>>
>>> 2018-02-15 09:31:13,952 DEBUG 
>>> [org.apereo.cas.authentication.RegisteredServiceAuthenticationHandlerResolver]
>>>  
>>> - >>

[cas-user] Re: CAS 5.2.2 with MFA using Google Authenticator / GAuth

2019-02-21 Thread Jeremy Van Rooyen

Hi Mickaël,

Thanks for your reply.

So after playing around a bit more it seems like the on screen scratch 
codes is being stored in the mongodb and using that it allows me to 
authenticate perfectly.

The next question is how would one register via the qrcode using the Google 
Authenticator app on phone? Or am I not understanding something?

Kind Regards
Jeremy

On Tuesday, 19 February 2019 10:30:29 UTC+2, Mickaël wrote:
>
> Hello,
>
> Are you sure there is anything register in your Mongo database ? Scratch 
> codes and token are store in DB for each user in 2 different tables.
>
> It is strange to see that, normally "WHO" is the user, not the token :
> *WHO: 253227*
> *WHAT: Supplied credentials: [[token=253227]]*
>
> For information, I am using gauth with MariaDB without any issue.
>
> Mickaël
>
> Le jeudi 15 février 2018 09:53:52 UTC+1, Janina Byky a écrit :
>>
>> Hello,
>>
>> I'm trying to setup CAS 5.2.2 with Google Authenticator as second auth 
>> factor for specified services. CAS is running over LDAP (AD) and GAuth 
>> based on mongo. So far everything was great, build succeed, GAuth qrcode 
>> appears, user registers and now it's time for TOKEN form. I'm typing all 
>> scratch codes and those generated by Google Authenticator, but every single 
>> attempt is unsuccessful. Also there's no collection created to store tokens 
>> in mongo. Only GAuthRepository is created with proper values of registered 
>> users.
>>
>> *cas.properties*
>>
>> cas.authn.accept.users=
>>
>> cas.authn.ldap[0].order=0
>> cas.authn.ldap[0].type=AUTHENTICATED
>> cas.authn.ldap[0].ldapUrl={CUT}
>> cas.authn.ldap[0].connectionStrategy=DEFAULT
>> cas.authn.ldap[0].useSsl=true
>> cas.authn.ldap[0].connectTimeout=15000
>> cas.authn.ldap[0].subtreeSearch=true
>> cas.authn.ldap[0].baseDn={CUT}
>>
>> cas.authn.ldap[0].userFilter=(|(sAMAccountName={user})(userPrincipalName={user}))
>> cas.authn.ldap[0].bindDn={CUT}
>> cas.authn.ldap[0].bindCredential={CUT}
>> cas.authn.ldap[0].enhanceWithEntryResolver=true
>> cas.authn.ldap[0].principalAttributeId=sAMAccountName
>> cas.authn.ldap[0].principalAttributePassword=
>> cas.authn.ldap[0].usePasswordPolicy=true
>>
>> cas.authn.ldap[0].principalAttributeList=sn,cn:commonName,givenName,sAMAccountName,memberOf
>> cas.authn.ldap[0].allowMultiplePrincipalAttributeValues=true
>> cas.authn.ldap[0].poolPassivator=NONE
>> cas.authn.ldap[0].minPoolSize=2
>> cas.authn.ldap[0].maxPoolSize=15
>>
>>
>> cas.authn.mfa.globalProviderId=mfa-gauth
>> cas.authn.mfa.globalFailureMode=CLOSED
>>
>> cas.authn.mfa.gauth.issuer=TEST
>> cas.authn.mfa.gauth.codeDigits=6
>> cas.authn.mfa.gauth.timeStepSize=60
>> cas.authn.mfa.gauth.windowSize=3
>> cas.authn.mfa.gauth.label=TEST
>> cas.authn.mfa.gauth.rank=0
>>
>> cas.authn.mfa.gauth.cleaner.enabled=true
>> cas.authn.mfa.gauth.cleaner.schedule.startDelay=2
>> cas.authn.mfa.gauth.cleaner.schedule.repeatInterval=6
>>
>> cas.authn.mfa.gauth.bypass.type=DEFAULT
>>
>> cas.authn.mfa.gauth.mongo.clientUri=${mongo.uri}
>> cas.authn.mfa.gauth.mongo.dropCollection=false
>> cas.authn.mfa.gauth.mongo.collection=GAuthRepository
>>
>> cas.authn.mfa.gauth.mongo.tokenCollection=GoogleAuthenticatorMongoDbTokenRepository
>>
>>
>>
>> *pom.xml*
>>
>> 
>> org.apereo.cas
>> cas-server-webapp${app.server}
>> ${cas.version}
>> war
>> runtime
>> 
>> 
>> org.apereo.cas
>> cas-server-support-ldap
>> ${cas.version}
>> 
>> 
>> org.apereo.cas
>> cas-server-support-saml
>> ${cas.version}
>> 
>> 
>> org.apereo.cas
>> cas-server-support-gauth
>> ${cas.version}
>> 
>> 
>> org.apereo.cas
>> cas-server-support-gauth-mongo
>> ${cas.version}
>> 
>>
>>
>> *catalina.log*
>>
>> 2018-02-15 09:31:13,952 DEBUG 
>> [org.apereo.cas.authentication.RegisteredServiceAuthenticationHandlerResolver]
>>  
>> - > [GoogleAuthenticatorAuthenticationHandler,LdapAuthenticationHandler,HttpBasedServiceCredentialsAuthenticationHandler]>
>> 2018-02-15 09:31:13,953 DEBUG 
>> [org.apereo.cas.adaptors.gauth.GoogleAuthenticatorAuthenticationHandler] - 
>> 
>> 2018-02-15 09:31:13,954 DEBUG 
>> [org.apereo.cas.adaptors.gauth.GoogleAuthenticatorAuthenticationHandler] - 
>> 
>> 2018-02-15 09:31:13,970 DEBUG 
>> [org.apereo.cas.authentication.PolicyBasedAuthenticationManager] - 
>> <[GoogleAuthenticatorAuthenticationHandler] exception details: [Failed to 
>> authenticate code *253227*].>
>> 2018-02-15 09:31:13,971 DEBUG 
>> [org.apereo.cas.authentication.handler.support.AbstractUsernamePasswordAuthenticationHandler]
>>  
>> - > handler [LdapAuthenticationHandler]>
>> 2018-02-15 09:31:13,972 ERROR 
>> [org.apereo.cas.authentication.PolicyBasedAuthenticationManager] - 
>> <*Authentication 
>> has failed. Credentials may be incorrect or CAS cannot find

[cas-user] CAS-5.3.8 displays cas login page before rediecting to openid provider login screen

2019-02-21 Thread john

Hi , I upgraded Cas from 5.2.3 to 5.3.8 and when i try to use the 
url 
http://localhost:8080/cas/oauth2.0/authorize?response_type=code_id=_uri=http://localhost:8080/test,
 
cas displays default login page(For a second) before redirecting to OpenId 
provider login screen. I have set autoredirect to true for openid in 
cas.properties.

Any idea how to redirect to openid login screen without displaying cas 
login page.


Thanks



-- 
- 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 cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/82b20319-ba8b-4454-8d9d-9aceb6acde68%40apereo.org.

[cas-user] Re: Cas Resources Link

2019-02-21 Thread Andy Ng

Hi there,

Just got some testing done, it seems that either 
*environment.getPreperties()* *does not support list* or is bugged

Because I tested the following (copy from 
"https://stackoverflow.com/questions/39218966/what-is-null-safe-way-to-convert-array-to-string-using-thymeleaf;):


Which should show the list, but instead *it outputted null*.

So... I think your best bet is to use beans instead... Or maybe someone 
else have other ideas?

Cheers!
- Andy

-- 
- 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 cas-user+unsubscr...@apereo.org.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/cc53375f-6421-4473-ba35-fd07bfa62773%40apereo.org.

Re: [cas-user] Re: CAS 5.2.2 with MFA using Google Authenticator / GAuth

[cas-user] How to register a service in CAS while using SAM2.0 protocol

[cas-user] Custom encoder with cas 5.3

[cas-user] Re: Cas Resources Link

Re: [cas-user] DUO ByPass unenrolled users broken?

Re: [cas-user] DUO ByPass unenrolled users broken?

Re: [cas-user] DUO ByPass unenrolled users broken?

Re: [cas-user] DUO ByPass unenrolled users broken?

Re: [cas-user] CAS-6.1.0-RC2 Invalid credentals

Re: [cas-user] DUO ByPass unenrolled users broken?

Re: [cas-user] DUO ByPass unenrolled users broken?

Re: [cas-user] DUO ByPass unenrolled users broken?

Re: [cas-user] Re: CAS 5.2.2 with MFA using Google Authenticator / GAuth

[cas-user] DUO ByPass unenrolled users broken?

[cas-user] Re: Cas Resources Link

[cas-user] Re: CAS-6.1.0-RC2 Invalid credentals

[cas-user] Re: CAS 5.2.2 with MFA using Google Authenticator / GAuth

[cas-user] Re: CAS 5.2.2 with MFA using Google Authenticator / GAuth

[cas-user] Re: CAS 5.2.2 with MFA using Google Authenticator / GAuth

[cas-user] CAS-5.3.8 displays cas login page before rediecting to openid provider login screen

[cas-user] Re: Cas Resources Link

21 matches

Site Navigation

Mail list logo

Footer information