[cas-user] Authentication Succeeds, but Authentication Failer handles due to "attribute not found"

2015-09-22 Thread Kate Gray
Hello,

I have set up a minimal OpenLDAP installation and attempted to follow the 4.1 
authentication instructions.  I have a simple test setup, where the DN is in a 
format string to make things easier.

Authentication itself seems to succeed immediately, but the handler still 
fails, saying the attribute is missing.  The error logs look like this:

2015-09-22 14:57:03,634 DEBUG 
[org.ldaptive.auth.PooledBindAuthenticationHandler] - ldap://ldap-01.corecodec.com/,
 connectTimeout=3000, responseTimeout=-1, 
sslConfig=[org.ldaptive.ssl.SslConfig@175268509::credentialConfig=[org.ldaptive.ssl.X509CredentialConfig@505154363::trustCertificates=file://etc/ssl/certs/ldap.crt,
 authenticationCertificate=null, authenticationKey=null], trustManagers=null, 
enabledCipherSuites=null, enabledProtocols=null, 
handshakeCompletedListeners=null], useSSL=false, useStartTLS=true, 
connectionInitializer=null], 
providerConnectionFactory=[org.ldaptive.provider.jndi.JndiStartTLSConnectionFactory@1814265440::metadata=[ldapUrl=ldap://ldap-01.corecodec.com/,
 count=1], 
environment={java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, 
com.sun.jndi.ldap.connect.timeout=3000, java.naming.ldap.version=3}, 
providerConfig=[org.ldaptive.provider.jndi.JndiProviderConfig@238946327::operationExceptionResultCodes=[PROTOCOL_ERROR,
 SERVER_DOWN], properties={}, 
connectionStrategy=org.ldaptive.provider.ConnectionStrategies$DefaultConnectionStrategy@15592091,
 controlProcessor=org.ldaptive.provider.ControlProcessor@50d692d0, 
environment=null, tracePackets=null, removeDnUrls=true, 
searchIgnoreResultCodes=[TIME_LIMIT_EXCEEDED, SIZE_LIMIT_EXCEEDED, 
PARTIAL_RESULTS], sslSocketFactory=null, hostnameVerifier=null], 
sslSocketFactory=[org.ldaptive.ssl.TLSSocketFactory@1685441284::factory=sun.security.ssl.SSLSocketFactoryImpl@7163a722,
 
sslConfig=[org.ldaptive.ssl.SslConfig@175268509::credentialConfig=[org.ldaptive.ssl.X509CredentialConfig@505154363::trustCertificates=file://etc/ssl/certs/ldap.crt,
 authenticationCertificate=null, authenticationKey=null], trustManagers=null, 
enabledCipherSuites=null, enabledProtocols=null, 
handshakeCompletedListeners=null]], hostnameVerifier=null], 
providerConnection=org.ldaptive.provider.jndi.JndiStartTLSConnection@a85254f], 
result=true, resultCode=SUCCESS, message=null, controls=null] for 
criteria=[org.ldaptive.auth.AuthenticationCriteria@1495557037::dn=uid=test,ou=users,dc=identity,dc=corecodec,dc=com,
 
authenticationRequest=[org.ldaptive.auth.AuthenticationRequest@153672333::user=test,
 retAttrs=[1.1]]]>

2015-09-22 14:57:03,637 INFO [org.ldaptive.auth.Authenticator] - 


2015-09-22 14:57:03,649 DEBUG [org.ldaptive.auth.Authenticator] - ldap://ldap-01.corecodec.com/,
 connectTimeout=3000, responseTimeout=-1, 
sslConfig=[org.ldaptive.ssl.SslConfig@175268509::credentialConfig=[org.ldaptive.ssl.X509CredentialConfig@505154363::trustCertificates=file://etc/ssl/certs/ldap.crt,
 authenticationCertificate=null, authenticationKey=null], trustManagers=null, 
enabledCipherSuites=null, enabledProtocols=null, 
handshakeCompletedListeners=null], useSSL=false, useStartTLS=true, 
connectionInitializer=null], 
providerConnectionFactory=[org.ldaptive.provider.jndi.JndiStartTLSConnectionFactory@1814265440::metadata=[ldapUrl=ldap://ldap-01.corecodec.com/,
 count=1], 
environment={java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, 
com.sun.jndi.ldap.connect.timeout=3000, java.naming.ldap.version=3}, 
providerConfig=[org.ldaptive.provider.jndi.JndiProviderConfig@238946327::operationExceptionResultCodes=[PROTOCOL_ERROR,
 SERVER_DOWN], properties={}, 
connectionStrategy=org.ldaptive.provider.ConnectionStrategies$DefaultConnectionStrategy@15592091,
 controlProcessor=org.ldaptive.provider.ControlProcessor@50d692d0, 
environment=null, tracePackets=null, removeDnUrls=true, 
searchIgnoreResultCodes=[TIME_LIMIT_EXCEEDED, SIZE_LIMIT_EXCEEDED, 
PARTIAL_RESULTS], sslSocketFactory=null, hostnameVerifier=null], 
sslSocketFactory=[org.ldaptive.ssl.TLSSocketFactory@1685441284::factory=sun.security.ssl.SSLSocketFactoryImpl@7163a722,
 
sslConfig=[org.ldaptive.ssl.SslConfig@175268509::credentialConfig=[org.ldaptive.ssl.X509CredentialConfig@505154363::trustCertificates=file://etc/ssl/certs/ldap.crt,
 authenticationCertificate=null, authenticationKey=null], trustManagers=null, 
enabledCipherSuites=null, enabledProtocols=null, 
handshakeCompletedListeners=null]], hostnameVerifier=null], 
providerConnection=org.ldaptive.provider.jndi.JndiStartTLSConnection@a85254f], 
result=true, resultCode=SUCCESS, message=null, controls=null] for 
dn=uid=test,ou=users,dc=identity,dc=corecodec,dc=com with 
request=[org.ldaptive.auth.AuthenticationRequest@153672333::user=test, 
retAttrs=[1.1]]>

2015-09-22 14:57:03,651 DEBUG 
[org.jasig.cas.authentication.LdapAuthenticationHandler] - 

2015-09-22 14:57:03,658 INFO 
[org.jasig.cas.authentication.PolicyBasedAuthenticationManager] - 


2015-09-22 14:57:03,658 DEBUG 

Re: [cas-user] Authentication Succeeds, but Authentication Failer handles due to "attribute not found"

2015-09-22 Thread Nicolás

Hi Kate,

I've just passed this through, after smashing my head a few hours 
against the wall :-) In order to have the 4.1.x LDAP authentication 
working, you should deploy SAML configuration as well. Just follow the 
instructions at 
http://jasig.github.io/cas/4.1.x/protocol/SAML-Protocol.html, afterwards 
the authentication should work.


Regards,

Nicolás

El 22/09/15 a las 20:09, Kate Gray escribió:

Hello,

I have set up a minimal OpenLDAP installation and attempted to follow 
the 4.1 authentication instructions.  I have a simple test setup, 
where the DN is in a format string to make things easier.


Authentication itself seems to succeed immediately, but the handler 
still fails, saying the attribute is missing.  The error logs look 
like this:


2015-09-22 14:57:03,634 DEBUG 
[org.ldaptive.auth.PooledBindAuthenticationHandler] - response=[org.ldaptive.auth.AuthenticationHandlerResponse@255464314::connection=[org.ldaptive.DefaultConnectionFactory$DefaultConnection@1497009408::config=[org.ldaptive.ConnectionConfig@1452978425::ldapUrl=ldap://ldap-01.corecodec.com/, 
connectTimeout=3000, responseTimeout=-1, 
sslConfig=[org.ldaptive.ssl.SslConfig@175268509::credentialConfig=[org.ldaptive.ssl.X509CredentialConfig@505154363::trustCertificates=file://etc/ssl/certs/ldap.crt, 
authenticationCertificate=null, authenticationKey=null], 
trustManagers=null, enabledCipherSuites=null, enabledProtocols=null, 
handshakeCompletedListeners=null], useSSL=false, useStartTLS=true, 
connectionInitializer=null], 
providerConnectionFactory=[org.ldaptive.provider.jndi.JndiStartTLSConnectionFactory@1814265440::metadata=[ldapUrl=ldap://ldap-01.corecodec.com/, 
count=1], 
environment={java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, 
com.sun.jndi.ldap.connect.timeout=3000, java.naming.ldap.version=3}, 
providerConfig=[org.ldaptive.provider.jndi.JndiProviderConfig@238946327::operationExceptionResultCodes=[PROTOCOL_ERROR, 
SERVER_DOWN], properties={}, 
connectionStrategy=org.ldaptive.provider.ConnectionStrategies$DefaultConnectionStrategy@15592091, 
controlProcessor=org.ldaptive.provider.ControlProcessor@50d692d0, 
environment=null, tracePackets=null, removeDnUrls=true, 
searchIgnoreResultCodes=[TIME_LIMIT_EXCEEDED, SIZE_LIMIT_EXCEEDED, 
PARTIAL_RESULTS], sslSocketFactory=null, hostnameVerifier=null], 
sslSocketFactory=[org.ldaptive.ssl.TLSSocketFactory@1685441284::factory=sun.security.ssl.SSLSocketFactoryImpl@7163a722, 
sslConfig=[org.ldaptive.ssl.SslConfig@175268509::credentialConfig=[org.ldaptive.ssl.X509CredentialConfig@505154363::trustCertificates=file://etc/ssl/certs/ldap.crt, 
authenticationCertificate=null, authenticationKey=null], 
trustManagers=null, enabledCipherSuites=null, enabledProtocols=null, 
handshakeCompletedListeners=null]], hostnameVerifier=null], 
providerConnection=org.ldaptive.provider.jndi.JndiStartTLSConnection@a85254f], 
result=true, resultCode=SUCCESS, message=null, controls=null] for 
criteria=[org.ldaptive.auth.AuthenticationCriteria@1495557037::dn=uid=test,ou=users,dc=identity,dc=corecodec,dc=com, 
authenticationRequest=[org.ldaptive.auth.AuthenticationRequest@153672333::user=test, 
retAttrs=[1.1]]]>


2015-09-22 14:57:03,637 INFO [org.ldaptive.auth.Authenticator] - 
uid=test,ou=users,dc=identity,dc=corecodec,dc=com>


2015-09-22 14:57:03,649 DEBUG [org.ldaptive.auth.Authenticator] - 
response=[org.ldaptive.auth.AuthenticationHandlerResponse@255464314::connection=[org.ldaptive.DefaultConnectionFactory$DefaultConnection@1497009408::config=[org.ldaptive.ConnectionConfig@1452978425::ldapUrl=ldap://ldap-01.corecodec.com/, 
connectTimeout=3000, responseTimeout=-1, 
sslConfig=[org.ldaptive.ssl.SslConfig@175268509::credentialConfig=[org.ldaptive.ssl.X509CredentialConfig@505154363::trustCertificates=file://etc/ssl/certs/ldap.crt, 
authenticationCertificate=null, authenticationKey=null], 
trustManagers=null, enabledCipherSuites=null, enabledProtocols=null, 
handshakeCompletedListeners=null], useSSL=false, useStartTLS=true, 
connectionInitializer=null], 
providerConnectionFactory=[org.ldaptive.provider.jndi.JndiStartTLSConnectionFactory@1814265440::metadata=[ldapUrl=ldap://ldap-01.corecodec.com/, 
count=1], 
environment={java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, 
com.sun.jndi.ldap.connect.timeout=3000, java.naming.ldap.version=3}, 
providerConfig=[org.ldaptive.provider.jndi.JndiProviderConfig@238946327::operationExceptionResultCodes=[PROTOCOL_ERROR, 
SERVER_DOWN], properties={}, 
connectionStrategy=org.ldaptive.provider.ConnectionStrategies$DefaultConnectionStrategy@15592091, 
controlProcessor=org.ldaptive.provider.ControlProcessor@50d692d0, 
environment=null, tracePackets=null, removeDnUrls=true, 
searchIgnoreResultCodes=[TIME_LIMIT_EXCEEDED, SIZE_LIMIT_EXCEEDED, 
PARTIAL_RESULTS], sslSocketFactory=null, hostnameVerifier=null], 
sslSocketFactory=[org.ldaptive.ssl.TLSSocketFactory@1685441284::factory=sun.security.ssl.SSLSocketFactoryImpl@7163a722, 

[cas-user] CAS returns to the main page instead of authenticating

2015-09-22 Thread Nicolás
Hi,

What can be generating the behavior described in the log below? Each 
time an application tries to authenticate with CAS, it just returns 
again to the CAS main page. No error, no warning, nothing. Just like if 
I just accessed /cas. Especially significant seems this line:

2015-09-22 18:28:26,233 ERROR
[org.jasig.cas.ticket.registry.JpaTicketRegistry] - Error getting
ticket
[TGT-**Bd1falzoKR-mydomain.com,
javax.persistence.TransactionRequiredException: no transaction is in
progress] from registry.


What can be the problem? I followed the guide for JPA at 
http://jasig.github.io/cas/4.1.x/installation/JPA-Ticket-Registry.html 
for CAS 4.1.x.

2015-09-22 18:28:26,123 DEBUG
[org.jasig.cas.audit.spi.TicketOrCredentialPrincipalResolver] -


2015-09-22 18:28:26,130 INFO
[org.jasig.inspektr.audit.support.Slf4jLoggingAuditTrailManager] -
Audit trail record BEGIN
=
WHO: myuser+password
WHAT: supplied credentials: [myuser+password]
ACTION: AUTHENTICATION_SUCCESS
APPLICATION: CAS
WHEN: Tue Sep 22 18:28:26 WEST 2015
CLIENT IP ADDRESS: 192.168.1.X
SERVER IP ADDRESS: 192.168.1.Y
=

2015-09-22 18:28:26,138 DEBUG
[org.jasig.cas.ticket.registry.JpaTicketRegistry] - Added ticket
[TGT-**Bd1falzoKR-mydomain.com]
to registry.

2015-09-22 18:28:26,138 DEBUG
[org.jasig.cas.ticket.registry.JpaTicketRegistry] - 
Hibernate: insert into TICKETGRANTINGTICKET (NUMBER_OF_TIMES_USED,
CREATION_TIME, EXPIRATION_POLICY, LAST_TIME_USED,
PREVIOUS_LAST_TIME_USED, ticketGrantingTicket_ID, AUTHENTICATION,
EXPIRED, PROXIED_BY, SERVICES_GRANTED_ACCESS_TO,
SUPPLEMENTAL_AUTHENTICATIONS, ID) values (?, ?, ?, ?, ?, ?, ?, ?, ?,
?, ?, ?)
Hibernate: update TICKETGRANTINGTICKET set NUMBER_OF_TIMES_USED=?,
CREATION_TIME=?, EXPIRATION_POLICY=?, LAST_TIME_USED=?,
PREVIOUS_LAST_TIME_USED=?, ticketGrantingTicket_ID=?,
AUTHENTICATION=?, EXPIRED=?, PROXIED_BY=?,
SERVICES_GRANTED_ACCESS_TO=?, SUPPLEMENTAL_AUTHENTICATIONS=? where ID=?

2015-09-22 18:28:26,193 DEBUG
[org.jasig.cas.audit.spi.TicketOrCredentialPrincipalResolver] -


2015-09-22 18:28:26,195 INFO
[org.jasig.inspektr.audit.support.Slf4jLoggingAuditTrailManager] -
Audit trail record BEGIN
=
WHO: myuser+password
WHAT:
TGT-**Bd1falzoKR-mydomain.com
ACTION: TICKET_GRANTING_TICKET_CREATED
APPLICATION: CAS
WHEN: Tue Sep 22 18:28:26 WEST 2015
CLIENT IP ADDRESS: 192.168.1.X
SERVER IP ADDRESS: 192.168.1.Y
=


2015-09-22 18:28:26,195 INFO
[org.jasig.inspektr.audit.support.Slf4jLoggingAuditTrailManager] -
Audit trail record BEGIN
=
WHO: myuser+password
WHAT:
TGT-**Bd1falzoKR-mydomain.com
ACTION: TICKET_GRANTING_TICKET_CREATED
APPLICATION: CAS
WHEN: Tue Sep 22 18:28:26 WEST 2015
CLIENT IP ADDRESS: 192.168.1.X
SERVER IP ADDRESS: 192.168.1.Y
=

2015-09-22 18:28:26,203 DEBUG
[org.jasig.cas.web.support.CookieRetrievingCookieGenerator] -
Removed cookie with name [CASPRIVACY]

2015-09-22 18:28:26,214 DEBUG
[org.jasig.cas.web.support.DefaultCasCookieValueManager] - Encoding
cookie value

[TGT-**Bd1falzoKR-mydomain.com@192.168.1.X@Mozilla/5.0
(X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu
Chromium/44.0.2403.89 Chrome/44.0.2403.89 Safari/537.36]

2015-09-22 18:28:26,214 DEBUG
[org.jasig.cas.web.support.DefaultCasCookieValueManager] - 

2015-09-22 18:28:26,215 DEBUG
[org.jasig.cas.util.DefaultCipherExecutor] - 

2015-09-22 18:28:26,219 DEBUG
[org.jasig.cas.web.support.CookieRetrievingCookieGenerator] - 

2015-09-22 18:28:26,233 ERROR
[org.jasig.cas.ticket.registry.JpaTicketRegistry] - Error getting
ticket
[TGT-**Bd1falzoKR-mydomain.com,
javax.persistence.TransactionRequiredException: no transaction is in
progress] from registry.

2015-09-22 18:28:26,240 DEBUG
[org.jasig.cas.CentralAuthenticationServiceImpl] - Ticket
[TGT-**Bd1falzoKR-mydomain.com]
by type [TicketGrantingTicket] cannot be found in the ticket registry.

2015-09-22 18:28:26,248 DEBUG
[org.jasig.cas.audit.spi.TicketOrCredentialPrincipalResolver] -
Resolving argument [String] for audit

2015-09-22 

[cas-user] CAS method=POST parameter with Duo MFA

2015-09-22 Thread Alex Olson
We’re experiencing the issue as described here: 
https://groups.google.com/forum/#!topic/jasig-cas-user/Md834S7eoqA

With MFA integrated into CAS, CAS no longer seems to respect the method=POST 
parameter when sending the login response back to a requesting application. It 
sends a GET even when the login request from the application requested a POST. 
How do we edit the web flow to make this work?

Thanks!
-- Alex

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user


Re: [cas-user] Authentication Succeeds, but Authentication Failer handles due to "attribute not found"

2015-09-22 Thread Kate Gray
That’s bizarre.  Adding in the SAML dependency fixed the issue.

Thank you :)



On 2015-09-22, 12:14 PM, "Nicolás"  wrote:

>Hi Kate,
>
>I've just passed this through, after smashing my head a few hours 
>against the wall :-) In order to have the 4.1.x LDAP authentication 
>working, you should deploy SAML configuration as well. Just follow the 
>instructions at 
>http://jasig.github.io/cas/4.1.x/protocol/SAML-Protocol.html, afterwards 
>the authentication should work.
>
>Regards,
>
>Nicolás
>
>El 22/09/15 a las 20:09, Kate Gray escribió:
>> Hello,
>>
>> I have set up a minimal OpenLDAP installation and attempted to follow 
>> the 4.1 authentication instructions.  I have a simple test setup, 
>> where the DN is in a format string to make things easier.
>>
>> Authentication itself seems to succeed immediately, but the handler 
>> still fails, saying the attribute is missing.  The error logs look 
>> like this:
>>
>> 2015-09-22 14:57:03,634 DEBUG 
>> [org.ldaptive.auth.PooledBindAuthenticationHandler] - > response=[org.ldaptive.auth.AuthenticationHandlerResponse@255464314::connection=[org.ldaptive.DefaultConnectionFactory$DefaultConnection@1497009408::config=[org.ldaptive.ConnectionConfig@1452978425::ldapUrl=ldap://ldap-01.corecodec.com/,
>>  
>> connectTimeout=3000, responseTimeout=-1, 
>> sslConfig=[org.ldaptive.ssl.SslConfig@175268509::credentialConfig=[org.ldaptive.ssl.X509CredentialConfig@505154363::trustCertificates=file://etc/ssl/certs/ldap.crt,
>>  
>> authenticationCertificate=null, authenticationKey=null], 
>> trustManagers=null, enabledCipherSuites=null, enabledProtocols=null, 
>> handshakeCompletedListeners=null], useSSL=false, useStartTLS=true, 
>> connectionInitializer=null], 
>> providerConnectionFactory=[org.ldaptive.provider.jndi.JndiStartTLSConnectionFactory@1814265440::metadata=[ldapUrl=ldap://ldap-01.corecodec.com/,
>>  
>> count=1], 
>> environment={java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, 
>> com.sun.jndi.ldap.connect.timeout=3000, java.naming.ldap.version=3}, 
>> providerConfig=[org.ldaptive.provider.jndi.JndiProviderConfig@238946327::operationExceptionResultCodes=[PROTOCOL_ERROR,
>>  
>> SERVER_DOWN], properties={}, 
>> connectionStrategy=org.ldaptive.provider.ConnectionStrategies$DefaultConnectionStrategy@15592091,
>>  
>> controlProcessor=org.ldaptive.provider.ControlProcessor@50d692d0, 
>> environment=null, tracePackets=null, removeDnUrls=true, 
>> searchIgnoreResultCodes=[TIME_LIMIT_EXCEEDED, SIZE_LIMIT_EXCEEDED, 
>> PARTIAL_RESULTS], sslSocketFactory=null, hostnameVerifier=null], 
>> sslSocketFactory=[org.ldaptive.ssl.TLSSocketFactory@1685441284::factory=sun.security.ssl.SSLSocketFactoryImpl@7163a722,
>>  
>> sslConfig=[org.ldaptive.ssl.SslConfig@175268509::credentialConfig=[org.ldaptive.ssl.X509CredentialConfig@505154363::trustCertificates=file://etc/ssl/certs/ldap.crt,
>>  
>> authenticationCertificate=null, authenticationKey=null], 
>> trustManagers=null, enabledCipherSuites=null, enabledProtocols=null, 
>> handshakeCompletedListeners=null]], hostnameVerifier=null], 
>> providerConnection=org.ldaptive.provider.jndi.JndiStartTLSConnection@a85254f],
>>  
>> result=true, resultCode=SUCCESS, message=null, controls=null] for 
>> criteria=[org.ldaptive.auth.AuthenticationCriteria@1495557037::dn=uid=test,ou=users,dc=identity,dc=corecodec,dc=com,
>>  
>> authenticationRequest=[org.ldaptive.auth.AuthenticationRequest@153672333::user=test,
>>  
>> retAttrs=[1.1]]]>
>>
>> 2015-09-22 14:57:03,637 INFO [org.ldaptive.auth.Authenticator] - 
>> > uid=test,ou=users,dc=identity,dc=corecodec,dc=com>
>>
>> 2015-09-22 14:57:03,649 DEBUG [org.ldaptive.auth.Authenticator] - 
>> > response=[org.ldaptive.auth.AuthenticationHandlerResponse@255464314::connection=[org.ldaptive.DefaultConnectionFactory$DefaultConnection@1497009408::config=[org.ldaptive.ConnectionConfig@1452978425::ldapUrl=ldap://ldap-01.corecodec.com/,
>>  
>> connectTimeout=3000, responseTimeout=-1, 
>> sslConfig=[org.ldaptive.ssl.SslConfig@175268509::credentialConfig=[org.ldaptive.ssl.X509CredentialConfig@505154363::trustCertificates=file://etc/ssl/certs/ldap.crt,
>>  
>> authenticationCertificate=null, authenticationKey=null], 
>> trustManagers=null, enabledCipherSuites=null, enabledProtocols=null, 
>> handshakeCompletedListeners=null], useSSL=false, useStartTLS=true, 
>> connectionInitializer=null], 
>> providerConnectionFactory=[org.ldaptive.provider.jndi.JndiStartTLSConnectionFactory@1814265440::metadata=[ldapUrl=ldap://ldap-01.corecodec.com/,
>>  
>> count=1], 
>> environment={java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, 
>> com.sun.jndi.ldap.connect.timeout=3000, java.naming.ldap.version=3}, 
>> providerConfig=[org.ldaptive.provider.jndi.JndiProviderConfig@238946327::operationExceptionResultCodes=[PROTOCOL_ERROR,
>>  
>> SERVER_DOWN], properties={}, 
>> connectionStrategy=org.ldaptive.provider.ConnectionStrategies$DefaultConnectionStrategy@15592091,
>>  
>> 

[cas-user] CAS 4.0 and 4.1 dependency to JRadius

2015-09-22 Thread Jaroslav Kacer
Hello CAS community!

We have recently encountered an issue in CAS 4.0 and 4.1 when building it 
locally. The JRadius plugin depends on JRadius 1.0.0, which should be placed in 
the following repository, according to the POM file:
http://coova-dev.s3.amazonaws.com/mvn

Unfortunately it seems that the repository is not available anymore and we are 
not able to find any other public repository with version 1.0.0.

Although we have the JRadius libraries cached locally, I'd like to ask whether 
you plan to update the dependency in 4.0 and 4.1 as you did it for 4.2 (I see a 
dependency to JRadius 1.1.5 hosted in the JitPack repository).

I'm aware of this bug report: https://github.com/coova/jradius/issues/1
But it is not clear if they plan to publish older versions into JitPack too.

Thank you!

Best Regards,
   Jarda

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user


[cas-user] substitute attribute for user

2015-09-22 Thread Chris Irwin
I have CAS 4.0 connected to AD.  This is working fine but I have one 
application that would like me to return a different value for the user.  Today 
they log in with the sAMAccount name and this is returned as CAS:user  I also 
return the employeeID as part of the claim.  It appears that their app can't 
extract the employeeID attribute from the claim and they want me to insert 
employeeID in the place of the sAMAccount name.  Can this be done?

Sincerely,

Christopher Irwin


-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user


Re: [cas-user] substitute attribute for user

2015-09-22 Thread Dmitriy Kopylenko
This could be accomplished by setting the ‘usernameAttribute’ property in the 
RegisteredService instance in question: 
http://jasig.github.io/cas/4.0.x/installation/Service-Management.html 


In CAS 4.1 this is even easier to do via a very flexible services management 
web app (with username attribute provider config options).

Check this demo out: http://jasigcasmgmt.herokuapp.com/ 
 and play with it by defining few 
registered services. You could login with casuser/Mellon

Best,
Dmitriy.

> On Sep 22, 2015, at 10:10 AM, Chris Irwin  wrote:
> 
> I have CAS 4.0 connected to AD.  This is working fine but I have one 
> application that would like me to return a different value for the user.  
> Today they log in with the sAMAccount name and this is returned as CAS:user  
> I also return the employeeID as part of the claim.  It appears that their app 
> can’t extract the employeeID attribute from the claim and they want me to 
> insert employeeID in the place of the sAMAccount name.  Can this be done?
>  
> Sincerely,
>  
> Christopher Irwin
>  
> -- 
> You are currently subscribed to cas-user@lists.jasig.org 
>  as: dkopyle...@unicon.net 
> 
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/cas-user 
> 

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

RE: [cas-user] CAS 4.0 and 4.1 dependency to JRadius

2015-09-22 Thread Misagh Moayyed
4.1 is already updated. We might be able to release a 4.0.6 that uses
jitpack, but since that would have CAS switch to 1.1.5 of jradius, it's
going to require a lot of changes to the radius module to work with 1.1.5.


So I'd recommend you try with 4.1 first. That should fix the dependency
problem. 

 

From: Jaroslav Kacer [mailto:jka...@idc.com] 
Sent: Tuesday, September 22, 2015 8:12 AM
To: cas-user@lists.jasig.org
Subject: [cas-user] CAS 4.0 and 4.1 dependency to JRadius

 

Hello CAS community!

 

We have recently encountered an issue in CAS 4.0 and 4.1 when building it
locally. The JRadius plugin depends on JRadius 1.0.0, which should be
placed in the following repository, according to the POM file:

http://coova-dev.s3.amazonaws.com/mvn

 

Unfortunately it seems that the repository is not available anymore and we
are not able to find any other public repository with version 1.0.0. 

 

Although we have the JRadius libraries cached locally, I'd like to ask
whether you plan to update the dependency in 4.0 and 4.1 as you did it for
4.2 (I see a dependency to JRadius 1.1.5 hosted in the JitPack
repository).

 

I'm aware of this bug report: https://github.com/coova/jradius/issues/1

But it is not clear if they plan to publish older versions into JitPack
too.

 

Thank you!

 

Best Regards,

   Jarda

 
-- 
You are currently subscribed to cas-user@lists.jasig.org
  as: mmoay...@unicon.net
 
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user