RE: [cas-user] single log out and login-webflow.xml
Regardless of how your TGT expires, when it does and whether it's manual or automatic via the expiration policy, SLO will initiate. You no longer have an SSO session, and you will be logged out every application you have authenticated to via CAS. Starting with 4.1 I think, you will have the ability to turn off SLO on a per application basis. If you have applications that tend to stay in use longer than your SSO session, you can exclude those from SLO, and when the user logs out, simply redirect that logout to the CAS logout and kill the session entirely. Another possibility is, your CAS client could keep your session alive by sending a heartbeat signal. This depends on your application and the client, whether it provides that feature. Even with that capability, assuming you use the default expiration policy the signal is only going to extend your inactivity timeout. Once you pass the hard timeout on the application side, you're back to the same issue. Most tend to turn off SLO entirely, for reasons that are SLO-specific and less CAS-specific some of which you have run into. From: Lapanja, Bob@POST [mailto:bob.lapa...@post.ca.gov] Sent: Thursday, August 13, 2015 2:10 PM To: cas-user@lists.jasig.org Subject: [cas-user] single log out and login-webflow.xml Using 4.0.0 I'm configuring single log out on some services and I have encountered a situation I would appreciate some clarity on. For this particular use case, we want the logout callback to be called if the user visits /cas/logout directly, but not when the TGT expires and is cleared out by the registry cleaner (accomplished thanks to logUserOutOfServices). Some users may spend a long time working in a single application. However, after doing some testing, I came across a third situation I hadn't considered. The user signs into ServiceA and continues actively using it, keeping the application session alive past the point where the TGT expires. The user then attempts to sign into ServiceB. At this point, it seems that login-webflow checks the TGT for validity, and if it is invalid calls terminateSessionAction.terminate, which fires the logout callbacks and logs the user out of ServiceA. Since this seems to be the same function called during logout-webflow, does that mean that this scenario must be considered to be the same as if the user explicitly visited /cas/logout, triggering the same logout callbacks? Since some (many) of our users have no concept of the distinction between the application session and the PASS session, the logout could be unexpected and the aborting of their active work could be frustrating. Am I missing something relevant about how people manage SLO's and users that may spend a lot of time in a single application at a time? Thank you for any information. -bob -- You are currently subscribed to cas-user@lists.jasig.org mailto:cas-user@lists.jasig.org as: mmoay...@unicon.net mailto: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
Re: [cas-user] CAS protocol flow sequence: AuthN then check service registry?
Sorry, I should have included that. Version 3.4.11. On Thu, Aug 13, 2015 at 10:42:17PM -0700, Misagh Moayyed wrote: But wouldn't it be better to check against the registry first and disallowing unauthorized service URLs before bothering with authentication? What CAS version are you on? That is the exact current behavior. -Original Message- From: Baron Fujimoto [mailto:ba...@hawaii.edu] Sent: Thursday, August 13, 2015 8:54 PM To: cas-user@lists.jasig.org Subject: [cas-user] CAS protocol flow sequence: AuthN then check service registry? Given the following scenario: CAS URL: https://cas.example.com Bogus unauthorized service URL: https://bogus.example.net Real authorized serviceURL : https://authorized.example.org User is tricked (by phish, perhaps) to visit https://cas.example.com/cas/login?service=https://bogus.example.net The user does not have an SSO session, so is presented with the CAS Login Form. The user submits the form with the username, password, and login ticket POSTed in the body. CAS authenticates the user and creates/sets an SSO session CASTGT cookie in the user's browser which contains the session key for the SSO session (TGT). It appears that at this point, CAS verifies the ?service= parameter against the registry of authorized service URLs. The user is presented with the Application Not Authorized error. However, by now the user has a valid TGT, and if they subsequently visit https://authorized.example.org, they will be able to utilize it to login via SSO. Is there any reason for concern here? I believe the scope of exposure is only limited to anyone who has access to the browser session (e.g. say, a publically accessible computer). But wouldn't it be better to check against the registry first and disallowing unauthorized service URLs before bothering with authentication? Or perhaps destroying the TGT if the service URL is unauthorized? Or am I missing something, or perhaps some best practices configuration of CAS to mitigate against this sort of situation? -baron -- Baron Fujimoto ba...@hawaii.edu :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum -- 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: ba...@hawaii.edu 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] Attribute Release
Chris,
Clearly I did not look closely enough at the logs.
In the log you have Created seed map='{username=[cirwin]}' for uid='cirwin'
followed by Generated query builder 'null' from query Map {username=[cirwin]}
In my log between these two lines I get Adding attribute 'uid' with value
'[rbon]' to query builder 'null'
followed by Generated query builder '(uid=rbon)' from query Map
{username=[rbon]}
In your configuration you have util:map id=queryAttributeMap
entry key=user value=uid /
/util:map
Try changing the key in the configuration from 'user' to 'username'.
Ray
From: Chris Irwin chris.ir...@sadasystems.com
Sent: August 14, 2015 05:02
To: cas-user@lists.jasig.org
Subject: RE:[cas-user] Attribute Release
Ray,
In the log below you can see the results of the query. You can also see the
attributes I have listed in the ldapAuthenticationHandler’s
principalAttributeMap get returned in the “Found principal attribute” This is
what I want to return back to the app but all I’m getting is the following:
cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'
cas:authenticationSuccess
cas:usercirwin/cas:user
/cas:authenticationSuccess
/cas:serviceResponse
I thought I just needed to wire up so that the attributes resolved here are
released:
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [sAMAccountName[CIrwin]]
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [cn[Chris Irwin]]
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [givenName[Chris]]
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [sn[Irwin]]
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [mail[chris.ir...@sadasystems.com]]
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [displayName[Chris Irwin]]
Is that different?
Chris
From: Ray Bon [mailto:r...@uvic.ca]
Sent: Thursday, August 13, 2015 6:17 PM
To: cas-user@lists.jasig.org
Subject: Re:[cas-user] Attribute Release
Check what attributes are being released from your LDAP server.
The items in the LDAP response may be provided as part of the authenticated
user info but not necessarily the released attributes.
Ray
From: Chris Irwin
chris.ir...@sadasystems.commailto:chris.ir...@sadasystems.com
Sent: August 13, 2015 13:58
To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org
Subject: [cas-user] Attribute Release
I'm not sure what i'm missing here. I can see the attributes resolved but they
are never released to the client:
2015-08-13 16:31:20,456 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Attempting LDAP
authentication for cirwin+password
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - LDAP response:
[org.ldaptive.auth.AuthenticationResponse@110158567::authenticationResultCode=AUTHENTICATION_HANDLER_SUCCESS,
ldapEntry=[dn=CN=Chris
Irwin,OU=SADA,OU=Consultants,dc=root,dc=njcu[[mail[chris.ir...@sadasystems.com]],
[uSNCreated[75502415]], [description[SADA Consultant]],
[whenChanged[20150805152738.0Z]], [objectClass[top, person,
organizationalPerson, user]], [primaryGroupID[513]], [givenName[Chris]],
[objectGUID[??D?a??[??]], [objectSid[ q??K9?l??u??V ]],
[instanceType[4]], [whenCreated[20150410141222.0Z]],
[dSCorePropagationData[20150520202442.0Z, 20150410142342.0Z,
1601010100.0Z]], [sn[Irwin]], [userAccountControl[66048]],
[lastLogonTimestamp[130832620538887202]], [cn[Chris Irwin]],
[sAMAccountName[CIrwin]], [sAMAccountType[805306368]],
[userPrincipalName[cir...@njcu.edu]], [displayName[Chris Irwin]],
[pwdLastSet[130731491217059125]], [name[Chris Irwin]],
[objectCategory[CN=Person,CN=Schema,CN=Configuration,DC=root,DC=njcu]],
[distinguishedName[CN=Chris Irwin,OU=SADA,OU=Consultants,DC=root,DC=njcu]],
[memberOf[CN=rdpadmins,CN=Users,DC=root,DC=njcu,
CN=VPN,CN=Users,DC=root,DC=njcu, CN=Domain Admins,CN=Users,DC=root,DC=njcu]],
[uSNChanged[90371268]]], responseControls=null, messageId=-1],
accountState=null, result=true, resultCode=SUCCESS, message=null, controls=null]
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [sAMAccountName[CIrwin]]
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [cn[Chris Irwin]]
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [givenName[Chris]]
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found
RE: [cas-user] Attribute Release
You are not getting anything from CAS because you’re not allowing any
attributes to be released. Your logs/config show you’re only resolving
attributes. Your service registry needs to release them next.
See:
http://jasig.github.io/cas/4.0.x/integration/Attribute-Release.html
From: Ray Bon [mailto:r...@uvic.ca]
Sent: Friday, August 14, 2015 10:25 AM
To: cas-user@lists.jasig.org
Subject: Re:[cas-user] Attribute Release
Chris,
Clearly I did not look closely enough at the logs.
In the log you have Created seed map='{username=[cirwin]}' for
uid='cirwin'
followed by Generated query builder 'null' from query Map
{username=[cirwin]}
In my log between these two lines I get Adding attribute 'uid' with value
'[rbon]' to query builder 'null'
followed by Generated query builder '(uid=rbon)' from query Map
{username=[rbon]}
In your configuration you have util:map id=queryAttributeMap
entry key=user value=uid /
/util:map
Try changing the key in the configuration from 'user' to 'username'.
Ray
_
From: Chris Irwin chris.ir...@sadasystems.com
mailto:chris.ir...@sadasystems.com
Sent: August 14, 2015 05:02
To: cas-user@lists.jasig.org mailto:cas-user@lists.jasig.org
Subject: RE:[cas-user] Attribute Release
Ray,
In the log below you can see the results of the query. You can also see the
attributes I have listed in the ldapAuthenticationHandler’s
principalAttributeMap get returned in the “Found principal attribute” This
is what I want to return back to the app but all I’m getting is the
following:
cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'
cas:authenticationSuccess
cas:usercirwin/cas:user
/cas:authenticationSuccess
/cas:serviceResponse
I thought I just needed to wire up so that the attributes resolved here are
released:
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [sAMAccountName[CIrwin]]
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [cn[Chris Irwin]]
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [givenName[Chris]]
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [sn[Irwin]]
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [mail[chris.ir...@sadasystems.com]]
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [displayName[Chris Irwin]]
Is that different?
Chris
From: Ray Bon [mailto:r...@uvic.ca]
Sent: Thursday, August 13, 2015 6:17 PM
To: cas-user@lists.jasig.org mailto:cas-user@lists.jasig.org
Subject: Re:[cas-user] Attribute Release
Check what attributes are being released from your LDAP server.
The items in the LDAP response may be provided as part of the authenticated
user info but not necessarily the released attributes.
Ray
_
From: Chris Irwin chris.ir...@sadasystems.com
mailto:chris.ir...@sadasystems.com
Sent: August 13, 2015 13:58
To: cas-user@lists.jasig.org mailto:cas-user@lists.jasig.org
Subject: [cas-user] Attribute Release
I'm not sure what i'm missing here. I can see the attributes resolved but
they are never released to the client:
2015-08-13 16:31:20,456 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Attempting LDAP
authentication for cirwin+password
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - LDAP response:
[org.ldaptive.auth.AuthenticationResponse@110158567::authenticationResultCode=AUTHENTICATION_HANDLER_SUCCESS,
ldapEntry=[dn=CN=Chris
Irwin,OU=SADA,OU=Consultants,dc=root,dc=njcu[[mail[chris.ir...@sadasystems.com]],
[uSNCreated[75502415]], [description[SADA Consultant]],
[whenChanged[20150805152738.0Z]], [objectClass[top, person,
organizationalPerson, user]], [primaryGroupID[513]], [givenName[Chris]],
[objectGUID[??D?a??[??]], [objectSid[ q??K9?l??u??V ]],
[instanceType[4]], [whenCreated[20150410141222.0Z]],
[dSCorePropagationData[20150520202442.0Z, 20150410142342.0Z,
1601010100.0Z]], [sn[Irwin]], [userAccountControl[66048]],
[lastLogonTimestamp[130832620538887202]], [cn[Chris Irwin]],
[sAMAccountName[CIrwin]], [sAMAccountType[805306368]],
[userPrincipalName[cir...@njcu.edu]], [displayName[Chris Irwin]],
[pwdLastSet[130731491217059125]], [name[Chris Irwin]],
[objectCategory[CN=Person,CN=Schema,CN=Configuration,DC=root,DC=njcu]],
[distinguishedName[CN=Chris Irwin,OU=SADA,OU=Consultants,DC=root,DC=njcu]],
[memberOf[CN=rdpadmins,CN=Users,DC=root,DC=njcu,
CN=VPN,CN=Users,DC=root,DC=njcu, CN=Domain
Admins,CN=Users,DC=root,DC=njcu]], [uSNChanged[90371268]]],
responseControls=null, messageId=-1], accountState=null, result=true,
resultCode=SUCCESS, message=null,
Re: [cas-user] CAS protocol flow sequence: AuthN then check service registry?
Yep, that’s old. That was the behavior which was changed to check service authorization before the author transaction start in 3.5.1+ (I don’t remember the exact 3.5.x version where it went in). Cheers, Dmitriy. On Aug 14, 2015, at 1:59 PM, Baron Fujimoto ba...@hawaii.edu wrote: Sorry, I should have included that. Version 3.4.11. On Thu, Aug 13, 2015 at 10:42:17PM -0700, Misagh Moayyed wrote: But wouldn't it be better to check against the registry first and disallowing unauthorized service URLs before bothering with authentication? What CAS version are you on? That is the exact current behavior. -Original Message- From: Baron Fujimoto [mailto:ba...@hawaii.edu] Sent: Thursday, August 13, 2015 8:54 PM To: cas-user@lists.jasig.org Subject: [cas-user] CAS protocol flow sequence: AuthN then check service registry? Given the following scenario: CAS URL: https://cas.example.com Bogus unauthorized service URL: https://bogus.example.net Real authorized serviceURL : https://authorized.example.org User is tricked (by phish, perhaps) to visit https://cas.example.com/cas/login?service=https://bogus.example.net The user does not have an SSO session, so is presented with the CAS Login Form. The user submits the form with the username, password, and login ticket POSTed in the body. CAS authenticates the user and creates/sets an SSO session CASTGT cookie in the user's browser which contains the session key for the SSO session (TGT). It appears that at this point, CAS verifies the ?service= parameter against the registry of authorized service URLs. The user is presented with the Application Not Authorized error. However, by now the user has a valid TGT, and if they subsequently visit https://authorized.example.org, they will be able to utilize it to login via SSO. Is there any reason for concern here? I believe the scope of exposure is only limited to anyone who has access to the browser session (e.g. say, a publically accessible computer). But wouldn't it be better to check against the registry first and disallowing unauthorized service URLs before bothering with authentication? Or perhaps destroying the TGT if the service URL is unauthorized? Or am I missing something, or perhaps some best practices configuration of CAS to mitigate against this sort of situation? -baron -- Baron Fujimoto ba...@hawaii.edu :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum -- 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: ba...@hawaii.edu 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: 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 protocol flow sequence: AuthN then check service registry?
Ok, thanks, that's helpful info. How backwards compatible is 3.5.x (or 3.6?) to 3.4x with regard to their configs? I'm assuming there's even more drift to the 4x stuff. I'm trying to get sense of what upgrading will entail. In the old docs, there are some guidelines for updating within the 3.4x or within the 3.5x lines, but not from 3.4x to other minor or major releases that I found. I did not find it in the newer http://jasig.github.io/ docs either, but I'm happy to RTFM if someone can provide a pointer (a search feature for the documentation may be helpful?). Aloha, -baron On Fri, Aug 14, 2015 at 02:02:01PM -0400, Dmitriy Kopylenko wrote: Yep, that’s old. That was the behavior which was changed to check service authorization before the author transaction start in 3.5.1+ (I don’t remember the exact 3.5.x version where it went in). Cheers, Dmitriy. On Aug 14, 2015, at 1:59 PM, Baron Fujimoto ba...@hawaii.edu wrote: Sorry, I should have included that. Version 3.4.11. On Thu, Aug 13, 2015 at 10:42:17PM -0700, Misagh Moayyed wrote: But wouldn't it be better to check against the registry first and disallowing unauthorized service URLs before bothering with authentication? What CAS version are you on? That is the exact current behavior. -Original Message- From: Baron Fujimoto [mailto:ba...@hawaii.edu] Sent: Thursday, August 13, 2015 8:54 PM To: cas-user@lists.jasig.org Subject: [cas-user] CAS protocol flow sequence: AuthN then check service registry? Given the following scenario: CAS URL: https://cas.example.com Bogus unauthorized service URL: https://bogus.example.net Real authorized serviceURL : https://authorized.example.org User is tricked (by phish, perhaps) to visit https://cas.example.com/cas/login?service=https://bogus.example.net The user does not have an SSO session, so is presented with the CAS Login Form. The user submits the form with the username, password, and login ticket POSTed in the body. CAS authenticates the user and creates/sets an SSO session CASTGT cookie in the user's browser which contains the session key for the SSO session (TGT). It appears that at this point, CAS verifies the ?service= parameter against the registry of authorized service URLs. The user is presented with the Application Not Authorized error. However, by now the user has a valid TGT, and if they subsequently visit https://authorized.example.org, they will be able to utilize it to login via SSO. Is there any reason for concern here? I believe the scope of exposure is only limited to anyone who has access to the browser session (e.g. say, a publically accessible computer). But wouldn't it be better to check against the registry first and disallowing unauthorized service URLs before bothering with authentication? Or perhaps destroying the TGT if the service URL is unauthorized? Or am I missing something, or perhaps some best practices configuration of CAS to mitigate against this sort of situation? -baron -- Baron Fujimoto ba...@hawaii.edu :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum -- 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: ba...@hawaii.edu 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: 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: ba...@hawaii.edu To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- Baron Fujimoto ba...@hawaii.edu :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum -- 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] Attribute Release
Misagh,
I have the LDAP component using this example:
bean id=ldapPersonAttributeDao
class=org.jasig.cas.persondir.LdapPersonAttributeDao
p:connectionFactory-ref=pooledLdapConnectionFactory
p:baseDN=${ldap.baseDn}
p:searchControls-ref=searchControls
p:searchFilter=mail={0}
property name=resultAttributeMapping
map
!--
| Key is LDAP attribute name, value is principal attribute name.
--
entry key=member value=member /
entry key=mail value=mail /
entry key=displayName value=displayName /
/map
/property
/bean
I believe I need to add this as well:
bean class=org.jasig.cas.services.RegisteredServiceImpl
property name=id value=0 /
property name=name value=HTTPS Services /
property name=description value=YOUR HTTP Service /
property name=serviceId value=https://**; /
property name=allowedAttributes
list
valueyourAttributeName/value
/list
/property
/bean
My question is, can I do this to release the same set of attributes for any
service? This looks like it’s going to require me to set this up for every new
service.
Sincerely,
Christopher Irwin
From: Misagh Moayyed [mailto:mmoay...@unicon.net]
Sent: Friday, August 14, 2015 1:50 PM
To: cas-user@lists.jasig.org
Subject: RE: [cas-user] Attribute Release
You are not getting anything from CAS because you’re not allowing any
attributes to be released. Your logs/config show you’re only resolving
attributes. Your service registry needs to release them next.
See:
http://jasig.github.io/cas/4.0.x/integration/Attribute-Release.html
From: Ray Bon [mailto:r...@uvic.ca]
Sent: Friday, August 14, 2015 10:25 AM
To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org
Subject: Re:[cas-user] Attribute Release
Chris,
Clearly I did not look closely enough at the logs.
In the log you have Created seed map='{username=[cirwin]}' for uid='cirwin'
followed by Generated query builder 'null' from query Map {username=[cirwin]}
In my log between these two lines I get Adding attribute 'uid' with value
'[rbon]' to query builder 'null'
followed by Generated query builder '(uid=rbon)' from query Map
{username=[rbon]}
In your configuration you have util:map id=queryAttributeMap
entry key=user value=uid /
/util:map
Try changing the key in the configuration from 'user' to 'username'.
Ray
From: Chris Irwin
chris.ir...@sadasystems.commailto:chris.ir...@sadasystems.com
Sent: August 14, 2015 05:02
To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org
Subject: RE:[cas-user] Attribute Release
Ray,
In the log below you can see the results of the query. You can also see the
attributes I have listed in the ldapAuthenticationHandler’s
principalAttributeMap get returned in the “Found principal attribute” This is
what I want to return back to the app but all I’m getting is the following:
cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'
cas:authenticationSuccess
cas:usercirwin/cas:user
/cas:authenticationSuccess
/cas:serviceResponse
I thought I just needed to wire up so that the attributes resolved here are
released:
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [sAMAccountName[CIrwin]]
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [cn[Chris Irwin]]
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [givenName[Chris]]
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [sn[Irwin]]
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [mail[chris.ir...@sadasystems.com]]
2015-08-13 16:31:20,565 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal
attribute: [displayName[Chris Irwin]]
Is that different?
Chris
From: Ray Bon [mailto:r...@uvic.ca]
Sent: Thursday, August 13, 2015 6:17 PM
To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org
Subject: Re:[cas-user] Attribute Release
Check what attributes are being released from your LDAP server.
The items in the LDAP response may be provided as part of the authenticated
user info but not necessarily the released attributes.
Ray
From: Chris Irwin
chris.ir...@sadasystems.commailto:chris.ir...@sadasystems.com
Sent: August 13, 2015 13:58
To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org
Subject: [cas-user] Attribute Release
I'm not sure what i'm missing here. I can see the attributes resolved but they
are never released to the client:
2015-08-13 16:31:20,456 DEBUG
[org.jasig.cas.authentication.LdapAuthenticationHandler] - Attempting LDAP
authentication for cirwin+password
RE:[cas-user] Attribute Release
Ray, In the log below you can see the results of the query. You can also see the attributes I have listed in the ldapAuthenticationHandler’s principalAttributeMap get returned in the “Found principal attribute” This is what I want to return back to the app but all I’m getting is the following: cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas' cas:authenticationSuccess cas:usercirwin/cas:user /cas:authenticationSuccess /cas:serviceResponse I thought I just needed to wire up so that the attributes resolved here are released: 2015-08-13 16:31:20,565 DEBUG [org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal attribute: [sAMAccountName[CIrwin]] 2015-08-13 16:31:20,565 DEBUG [org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal attribute: [cn[Chris Irwin]] 2015-08-13 16:31:20,565 DEBUG [org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal attribute: [givenName[Chris]] 2015-08-13 16:31:20,565 DEBUG [org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal attribute: [sn[Irwin]] 2015-08-13 16:31:20,565 DEBUG [org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal attribute: [mail[chris.ir...@sadasystems.com]] 2015-08-13 16:31:20,565 DEBUG [org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal attribute: [displayName[Chris Irwin]] Is that different? Chris From: Ray Bon [mailto:r...@uvic.ca] Sent: Thursday, August 13, 2015 6:17 PM To: cas-user@lists.jasig.org Subject: Re:[cas-user] Attribute Release Check what attributes are being released from your LDAP server. The items in the LDAP response may be provided as part of the authenticated user info but not necessarily the released attributes. Ray From: Chris Irwin chris.ir...@sadasystems.commailto:chris.ir...@sadasystems.com Sent: August 13, 2015 13:58 To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org Subject: [cas-user] Attribute Release I'm not sure what i'm missing here. I can see the attributes resolved but they are never released to the client: 2015-08-13 16:31:20,456 DEBUG [org.jasig.cas.authentication.LdapAuthenticationHandler] - Attempting LDAP authentication for cirwin+password 2015-08-13 16:31:20,565 DEBUG [org.jasig.cas.authentication.LdapAuthenticationHandler] - LDAP response: [org.ldaptive.auth.AuthenticationResponse@110158567::authenticationResultCode=AUTHENTICATION_HANDLER_SUCCESS, ldapEntry=[dn=CN=Chris Irwin,OU=SADA,OU=Consultants,dc=root,dc=njcu[[mail[chris.ir...@sadasystems.com]], [uSNCreated[75502415]], [description[SADA Consultant]], [whenChanged[20150805152738.0Z]], [objectClass[top, person, organizationalPerson, user]], [primaryGroupID[513]], [givenName[Chris]], [objectGUID[??D?a??[??]], [objectSid[ q??K9?l??u??V ]], [instanceType[4]], [whenCreated[20150410141222.0Z]], [dSCorePropagationData[20150520202442.0Z, 20150410142342.0Z, 1601010100.0Z]], [sn[Irwin]], [userAccountControl[66048]], [lastLogonTimestamp[130832620538887202]], [cn[Chris Irwin]], [sAMAccountName[CIrwin]], [sAMAccountType[805306368]], [userPrincipalName[cir...@njcu.edu]], [displayName[Chris Irwin]], [pwdLastSet[130731491217059125]], [name[Chris Irwin]], [objectCategory[CN=Person,CN=Schema,CN=Configuration,DC=root,DC=njcu]], [distinguishedName[CN=Chris Irwin,OU=SADA,OU=Consultants,DC=root,DC=njcu]], [memberOf[CN=rdpadmins,CN=Users,DC=root,DC=njcu, CN=VPN,CN=Users,DC=root,DC=njcu, CN=Domain Admins,CN=Users,DC=root,DC=njcu]], [uSNChanged[90371268]]], responseControls=null, messageId=-1], accountState=null, result=true, resultCode=SUCCESS, message=null, controls=null] 2015-08-13 16:31:20,565 DEBUG [org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal attribute: [sAMAccountName[CIrwin]] 2015-08-13 16:31:20,565 DEBUG [org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal attribute: [cn[Chris Irwin]] 2015-08-13 16:31:20,565 DEBUG [org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal attribute: [givenName[Chris]] 2015-08-13 16:31:20,565 DEBUG [org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal attribute: [sn[Irwin]] 2015-08-13 16:31:20,565 DEBUG [org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal attribute: [mail[chris.ir...@sadasystems.com]] 2015-08-13 16:31:20,565 DEBUG [org.jasig.cas.authentication.LdapAuthenticationHandler] - Found principal attribute: [displayName[Chris Irwin]] 2015-08-13 16:31:20,565 INFO [org.jasig.cas.authentication.PolicyBasedAuthenticationManager] - LdapAuthenticationHandler successfully authenticated cirwin+password 2015-08-13 16:31:20,565 DEBUG [org.jasig.cas.authentication.principal.PersonDirectoryPrincipalResolver] - Attempting to resolve a principal... 2015-08-13 16:31:20,565 DEBUG [org.jasig.cas.authentication.principal.PersonDirectoryPrincipalResolver] - Creating SimplePrincipal
