RE:[cas-user] Releasing attributes based upon the service URL
Thanks Misagh, that makes sense. I've got it working now. Regards, Richard -- 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] Releasing attributes based upon the service URL
Hi, I've a working instance of CAS that successfully returns certain attributes to any service that uses it. I now want to start returning attributes selectively based upon the service URL. I've duplicated the (sole) RegexRegisteredService bean in my deployerConfigContext.xml file, modifying only its ID, evaluationOrder and allowedAttributes list. However, I'm finding the resulting behaviour somewhat unpredictable! I haven't been able to work out what the significance of the evaluationOrder is. Are the beans tried in order, stopping when one matches? Or do they somehow build a list of attributes to release if multiple beans' serviceId regular expressions match? The main symptom is that no attributes seem to be released when I have more than one RegexRegisteredService bean, regardless of whether one or both match the serviceId. Is there some documentation that explains all this? Thanks, Richard -- 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] Java-sourced custom attributes not being released
Thanks Misagh. I've made some changes and now, just to be explicit, my authenticateUsernamePasswordInternal method ends: MapString, Object attributes = new HashMapString, Object(); if (billingAccountID != null) attributes.put(billingAccountId, billingAccountID); attributes.put(groupMembership, GROUP MEMBERSHIP INFORMATION); attributes.put(uid, UID INFORMATION); return createHandlerResult(credential, new SimplePrincipal(username, attributes), null); (I don't actually need the groupMembership and uid attributes but I noticed those names in the configuration file so hardwired them in case they would come through; now they're there just in case my billingAccountID is null.) My deployerConfigContext.xml now contains, directly inside the beans ... element: util:list id=registeredServicesList bean class=org.jasig.cas.services.RegexRegisteredService p:id=0 p:name=HTTP and IMAP p:description=Allows HTTP(S) and IMAP(S) protocols p:serviceId=^(https?|imaps?)://.* p:evaluationOrder=1001 / bean class=org.jasig.cas.services.RegisteredServiceImpl property name=id value=0 / property name=name value=HTTP Services / property name=description value=HTTP Services / property name=serviceId value=http://**; / property name=allowedAttributes list valuebillingAccountId/value valuegroupMembership/value valueuid/value /list /property /bean /util:list And I got rid of the attribute filter as you suggested. I *believe* this is all that should be required (reading http://jasig.github.io/cas/4.0.0/integration/Attribute-Release.html#configuration) but I'm still not getting any attributes through at all. Have I still missed a step? Thanks, Richard -- 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] Java-sourced custom attributes not being released
There are lots of commented-out elements from my various attempts and I've scrubbed out the database details but here it is. Thanks! -- 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?xml version=1.0 encoding=UTF-8? !-- Licensed to Jasig under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. Jasig licenses this file to you under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at the following location: http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- !-- | deployerConfigContext.xml centralizes into one file some of the declarative configuration that | all CAS deployers will need to modify. | | This file declares some of the Spring-managed JavaBeans that make up a CAS deployment. | The beans declared in this file are instantiated at context initialization time by the Spring | ContextLoaderListener declared in web.xml. It finds this file because this | file is among those declared in the context parameter contextConfigLocation. | | By far the most common change you will need to make in this file is to change the last bean | declaration to replace the default authentication handler with | one implementing your approach for authenticating usernames and passwords. +-- beans xmlns=http://www.springframework.org/schema/beans; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:p=http://www.springframework.org/schema/p; xmlns:c=http://www.springframework.org/schema/c; xmlns:tx=http://www.springframework.org/schema/tx; xmlns:util=http://www.springframework.org/schema/util; xmlns:sec=http://www.springframework.org/schema/security; xsi:schemaLocation=http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.2.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.2.xsd http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.2.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd; !-- | The authentication manager defines security policy for authentication by specifying at a minimum | the authentication handlers that will be used to authenticate credential. While the AuthenticationManager | interface supports plugging in another implementation, the default PolicyBasedAuthenticationManager should | be sufficient in most cases. +-- bean id=authenticationManager class=org.jasig.cas.authentication.PolicyBasedAuthenticationManager constructor-arg map !-- | IMPORTANT | Every handler requires a unique name. | If more than one instance of the same handler class is configured, you must explicitly | set its name to something other than its default name (typically the simple class name). -- entry key-ref=proxyAuthenticationHandler value-ref=proxyPrincipalResolver / entry key-ref=primaryAuthenticationHandler value-ref=primaryPrincipalResolver / /map /constructor-arg !-- Uncomment the metadata populator to allow clearpass to capture and cache the password This switch effectively will turn on clearpass. property name=authenticationMetaDataPopulators util:list bean class=org.jasig.cas.extension.clearpass.CacheCredentialsMetaDataPopulator c:credentialCache-ref=encryptedMap / /util:list /property -- !-- | Defines the security policy around authentication. Some alternative policies that ship with CAS: | | * NotPreventedAuthenticationPolicy - all credential must either pass or fail authentication | * AllAuthenticationPolicy - all presented credential must be authenticated successfully | * RequiredHandlerAuthenticationPolicy - specifies a handler that must authenticate its credential to pass -- property name=authenticationPolicy bean class=org.jasig.cas.authentication.AnyAuthenticationPolicy / /property /bean !-- Required for proxy
RE: [cas-user] Java-sourced custom attributes not being released
Thanks. So does CAS is not looking at your handler for attributes mean that the attributes supplied via the SimplePrincipal object are not being used? When you refer to 3 hardcoded attributes do you mean this block...? util:map id=attrRepoBackingMap entry key=uid value=uid / entry key=eduPersonAffiliation value=eduPersonAffiliation / entry key=groupMembership value=groupMembership / /util:map And if so, presumably because only uid and groupMembership are listed as allowedAttributes, only these two can be released? (Currently, no attributes are coming through into the serviceValidate response XML.) Also, when you say null out the resolver do you mean primaryPrincipalResolver? When I do that, my primaryAuthenticationHandler no longer works (or is used). Apologies, but I don't yet understand enough about CAS to confidently make assumptions! I'll turn on debug and see what it says. Regards, Richard -Original Message- From: Misagh Moayyed [mailto:mmoay...@unicon.net] Sent: 06 August 2014 09:24 To: cas-user@lists.jasig.org Subject: RE: [cas-user] Java-sourced custom attributes not being released CAS is not looking at your handler for attributes; it will take a look at your resolver which right now has 3 hardcoded attributes, two of which can be released. (if you want the handler to take precedence, null out the resolver) If you are not getting those two, up the CAS logging to DEBUG and see what's coming out. -Original Message- From: Richard Wiseman [mailto:richard.wise...@bt.com] Sent: Wednesday, August 6, 2014 12:58 AM To: cas-user@lists.jasig.org Subject: RE:[cas-user] Java-sourced custom attributes not being released There are lots of commented-out elements from my various attempts and I've scrubbed out the database details but here it is. Thanks! -- 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: richard.wise...@bt.com 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] Java-sourced custom attributes not being released
Interesting... As I think you expected, the log now contains: 2014-08-06 09:40:52,972 DEBUG [org.jasig.cas.services.support.RegisteredServiceDefaultAttributeFilter] - Found attribute [groupMembership] in the list of allowed attributes for service [HTTP Services] 2014-08-06 09:40:52,972 DEBUG [org.jasig.cas.services.support.RegisteredServiceDefaultAttributeFilter] - Found attribute [uid] in the list of allowed attributes for service [HTTP Services] But after those two lines, attributes are not mentioned again in the log and the returned XML still contains no attributes. Curious. Regards, Richard -Original Message- From: richard.wise...@bt.com [mailto:richard.wise...@bt.com] Sent: 06 August 2014 09:41 To: cas-user@lists.jasig.org Subject: RE: [cas-user] Java-sourced custom attributes not being released Thanks. So does CAS is not looking at your handler for attributes mean that the attributes supplied via the SimplePrincipal object are not being used? When you refer to 3 hardcoded attributes do you mean this block...? util:map id=attrRepoBackingMap entry key=uid value=uid / entry key=eduPersonAffiliation value=eduPersonAffiliation / entry key=groupMembership value=groupMembership / /util:map And if so, presumably because only uid and groupMembership are listed as allowedAttributes, only these two can be released? (Currently, no attributes are coming through into the serviceValidate response XML.) Also, when you say null out the resolver do you mean primaryPrincipalResolver? When I do that, my primaryAuthenticationHandler no longer works (or is used). Apologies, but I don't yet understand enough about CAS to confidently make assumptions! I'll turn on debug and see what it says. Regards, Richard -Original Message- From: Misagh Moayyed [mailto:mmoay...@unicon.net] Sent: 06 August 2014 09:24 To: cas-user@lists.jasig.org Subject: RE: [cas-user] Java-sourced custom attributes not being released CAS is not looking at your handler for attributes; it will take a look at your resolver which right now has 3 hardcoded attributes, two of which can be released. (if you want the handler to take precedence, null out the resolver) If you are not getting those two, up the CAS logging to DEBUG and see what's coming out. -Original Message- From: Richard Wiseman [mailto:richard.wise...@bt.com] Sent: Wednesday, August 6, 2014 12:58 AM To: cas-user@lists.jasig.org Subject: RE:[cas-user] Java-sourced custom attributes not being released There are lots of commented-out elements from my various attempts and I've scrubbed out the database details but here it is. Thanks! -- 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: richard.wise...@bt.com 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: richard.wise...@bt.com 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] Java-sourced custom attributes not being released
Thanks – that definitely helped! I’m getting there now. My log now contains: 2014-08-06 10:20:45,521 DEBUG [org.jasig.cas.services.support.RegisteredServiceDefaultAttributeFilter] - Found attribute [billingAccountId] in the list of allowed attributes for service [HTTP Services] 2014-08-06 10:20:45,521 DEBUG [org.jasig.cas.services.support.RegisteredServiceDefaultAttributeFilter] - Found attribute [groupMembership] in the list of allowed attributes for service [HTTP Services] 2014-08-06 10:20:45,522 DEBUG [org.jasig.cas.services.support.RegisteredServiceDefaultAttributeFilter] - Found attribute [uid] in the list of allowed attributes for service [HTTP Services] Still no attributes in the XML from serviceValidate though… Regards, Richard From: Misagh Moayyed [mailto:mmoay...@unicon.net] Sent: 06 August 2014 10:07 To: cas-user@lists.jasig.org Subject: RE: [cas-user] Java-sourced custom attributes not being released Answers inline. -Original Message- From: richard.wise...@bt.commailto:richard.wise...@bt.com [mailto:richard.wise...@bt.com] Sent: Wednesday, August 6, 2014 1:41 AM To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org Subject: RE: [cas-user] Java-sourced custom attributes not being released Thanks. So does CAS is not looking at your handler for attributes mean that the attributes supplied via the SimplePrincipal object are not being used? Correct. When you refer to 3 hardcoded attributes do you mean this block...? util:map id=attrRepoBackingMap entry key=uid value=uid / entry key=eduPersonAffiliation value=eduPersonAffiliation / entry key=groupMembership value=groupMembership / /util:map Yes. And if so, presumably because only uid and groupMembership are listed as allowedAttributes, only these two can be released? (Currently, no attributes are coming through into the serviceValidate response XML.) Yes. Also, when you say null out the resolver do you mean primaryPrincipalResolver? When I do that, my primaryAuthenticationHandler no longer works (or is used). Apologies, but I don't yet understand enough about CAS to confidently make assumptions! See: http://jasig.github.io/cas/development/installation/Configuring-Authentication-Components.html#principalresolver-vs-authenticationhandler I'll turn on debug and see what it says. Regards, Richard -Original Message- From: Misagh Moayyed [mailto:mmoay...@unicon.net] Sent: 06 August 2014 09:24 To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org Subject: RE: [cas-user] Java-sourced custom attributes not being released CAS is not looking at your handler for attributes; it will take a look at your resolver which right now has 3 hardcoded attributes, two of which can be released. (if you want the handler to take precedence, null out the resolver) If you are not getting those two, up the CAS logging to DEBUG and see what's coming out. -Original Message- From: Richard Wiseman [mailto:richard.wise...@bt.com] Sent: Wednesday, August 6, 2014 12:58 AM To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org Subject: RE:[cas-user] Java-sourced custom attributes not being released There are lots of commented-out elements from my various attempts and I've scrubbed out the database details but here it is. Thanks! -- You are currently subscribed to cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org as: mmoay...@unicon.netmailto: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.orgmailto:cas-user@lists.jasig.org as: richard.wise...@bt.commailto:richard.wise...@bt.com 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.orgmailto:cas-user@lists.jasig.org as: mmoay...@unicon.netmailto: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.orgmailto:cas-user@lists.jasig.org as: richard.wise...@bt.commailto:richard.wise...@bt.com 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] Java-sourced custom attributes not being released
I think I’ve found the problem! It’s using casServiceValidationSuccess.jsp from WEB-INF/view/jsp/protocol/2.0 not WEB-INF/view/jsp/protocol/3.0. Surely it should default to the 3.0 one if there are attributes, shouldn’t it? I can’t find any way of telling CAS that I am using the v3 protocol when I make the serviceValidate call… Regards, Richard From: richard.wise...@bt.com [mailto:richard.wise...@bt.com] Sent: 06 August 2014 10:28 To: cas-user@lists.jasig.org Subject: RE: [cas-user] Java-sourced custom attributes not being released Thanks – that definitely helped! I’m getting there now. My log now contains: 2014-08-06 10:20:45,521 DEBUG [org.jasig.cas.services.support.RegisteredServiceDefaultAttributeFilter] - Found attribute [billingAccountId] in the list of allowed attributes for service [HTTP Services] 2014-08-06 10:20:45,521 DEBUG [org.jasig.cas.services.support.RegisteredServiceDefaultAttributeFilter] - Found attribute [groupMembership] in the list of allowed attributes for service [HTTP Services] 2014-08-06 10:20:45,522 DEBUG [org.jasig.cas.services.support.RegisteredServiceDefaultAttributeFilter] - Found attribute [uid] in the list of allowed attributes for service [HTTP Services] Still no attributes in the XML from serviceValidate though… Regards, Richard From: Misagh Moayyed [mailto:mmoay...@unicon.net] Sent: 06 August 2014 10:07 To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org Subject: RE: [cas-user] Java-sourced custom attributes not being released Answers inline. -Original Message- From: richard.wise...@bt.commailto:richard.wise...@bt.com [mailto:richard.wise...@bt.com] Sent: Wednesday, August 6, 2014 1:41 AM To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org Subject: RE: [cas-user] Java-sourced custom attributes not being released Thanks. So does CAS is not looking at your handler for attributes mean that the attributes supplied via the SimplePrincipal object are not being used? Correct. When you refer to 3 hardcoded attributes do you mean this block...? util:map id=attrRepoBackingMap entry key=uid value=uid / entry key=eduPersonAffiliation value=eduPersonAffiliation / entry key=groupMembership value=groupMembership / /util:map Yes. And if so, presumably because only uid and groupMembership are listed as allowedAttributes, only these two can be released? (Currently, no attributes are coming through into the serviceValidate response XML.) Yes. Also, when you say null out the resolver do you mean primaryPrincipalResolver? When I do that, my primaryAuthenticationHandler no longer works (or is used). Apologies, but I don't yet understand enough about CAS to confidently make assumptions! See: http://jasig.github.io/cas/development/installation/Configuring-Authentication-Components.html#principalresolver-vs-authenticationhandler I'll turn on debug and see what it says. Regards, Richard -Original Message- From: Misagh Moayyed [mailto:mmoay...@unicon.net] Sent: 06 August 2014 09:24 To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org Subject: RE: [cas-user] Java-sourced custom attributes not being released CAS is not looking at your handler for attributes; it will take a look at your resolver which right now has 3 hardcoded attributes, two of which can be released. (if you want the handler to take precedence, null out the resolver) If you are not getting those two, up the CAS logging to DEBUG and see what's coming out. -Original Message- From: Richard Wiseman [mailto:richard.wise...@bt.com] Sent: Wednesday, August 6, 2014 12:58 AM To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org Subject: RE:[cas-user] Java-sourced custom attributes not being released There are lots of commented-out elements from my various attempts and I've scrubbed out the database details but here it is. Thanks! -- You are currently subscribed to cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org as: mmoay...@unicon.netmailto: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.orgmailto:cas-user@lists.jasig.org as: richard.wise...@bt.commailto:richard.wise...@bt.com 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.orgmailto:cas-user@lists.jasig.org as: mmoay...@unicon.netmailto: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.orgmailto:cas-user@lists.jasig.org as: richard.wise...@bt.commailto:richard.wise...@bt.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
RE: [cas-user] Java-sourced custom attributes not being released
Yep, that was it. I’ve (hopefully temporarily) copied the 3.0 version of casServiceValidationSuccess.jsp to 2.0 and it now shows the attributes. So all I now need is to be able to tall CAS I want it to use the 3.0 version of casServiceValidationSuccess.jsp. Regards, Richard From: richard.wise...@bt.com [mailto:richard.wise...@bt.com] Sent: 06 August 2014 11:14 To: cas-user@lists.jasig.org Subject: RE: [cas-user] Java-sourced custom attributes not being released I think I’ve found the problem! It’s using casServiceValidationSuccess.jsp from WEB-INF/view/jsp/protocol/2.0 not WEB-INF/view/jsp/protocol/3.0. Surely it should default to the 3.0 one if there are attributes, shouldn’t it? I can’t find any way of telling CAS that I am using the v3 protocol when I make the serviceValidate call… Regards, Richard From: richard.wise...@bt.com [mailto:richard.wise...@bt.com] Sent: 06 August 2014 10:28 To: cas-user@lists.jasig.org Subject: RE: [cas-user] Java-sourced custom attributes not being released Thanks – that definitely helped! I’m getting there now. My log now contains: 2014-08-06 10:20:45,521 DEBUG [org.jasig.cas.services.support.RegisteredServiceDefaultAttributeFilter] - Found attribute [billingAccountId] in the list of allowed attributes for service [HTTP Services] 2014-08-06 10:20:45,521 DEBUG [org.jasig.cas.services.support.RegisteredServiceDefaultAttributeFilter] - Found attribute [groupMembership] in the list of allowed attributes for service [HTTP Services] 2014-08-06 10:20:45,522 DEBUG [org.jasig.cas.services.support.RegisteredServiceDefaultAttributeFilter] - Found attribute [uid] in the list of allowed attributes for service [HTTP Services] Still no attributes in the XML from serviceValidate though… Regards, Richard From: Misagh Moayyed [mailto:mmoay...@unicon.net] Sent: 06 August 2014 10:07 To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org Subject: RE: [cas-user] Java-sourced custom attributes not being released Answers inline. -Original Message- From: richard.wise...@bt.commailto:richard.wise...@bt.com [mailto:richard.wise...@bt.com] Sent: Wednesday, August 6, 2014 1:41 AM To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org Subject: RE: [cas-user] Java-sourced custom attributes not being released Thanks. So does CAS is not looking at your handler for attributes mean that the attributes supplied via the SimplePrincipal object are not being used? Correct. When you refer to 3 hardcoded attributes do you mean this block...? util:map id=attrRepoBackingMap entry key=uid value=uid / entry key=eduPersonAffiliation value=eduPersonAffiliation / entry key=groupMembership value=groupMembership / /util:map Yes. And if so, presumably because only uid and groupMembership are listed as allowedAttributes, only these two can be released? (Currently, no attributes are coming through into the serviceValidate response XML.) Yes. Also, when you say null out the resolver do you mean primaryPrincipalResolver? When I do that, my primaryAuthenticationHandler no longer works (or is used). Apologies, but I don't yet understand enough about CAS to confidently make assumptions! See: http://jasig.github.io/cas/development/installation/Configuring-Authentication-Components.html#principalresolver-vs-authenticationhandler I'll turn on debug and see what it says. Regards, Richard -Original Message- From: Misagh Moayyed [mailto:mmoay...@unicon.net] Sent: 06 August 2014 09:24 To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org Subject: RE: [cas-user] Java-sourced custom attributes not being released CAS is not looking at your handler for attributes; it will take a look at your resolver which right now has 3 hardcoded attributes, two of which can be released. (if you want the handler to take precedence, null out the resolver) If you are not getting those two, up the CAS logging to DEBUG and see what's coming out. -Original Message- From: Richard Wiseman [mailto:richard.wise...@bt.com] Sent: Wednesday, August 6, 2014 12:58 AM To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org Subject: RE:[cas-user] Java-sourced custom attributes not being released There are lots of commented-out elements from my various attempts and I've scrubbed out the database details but here it is. Thanks! -- You are currently subscribed to cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org as: mmoay...@unicon.netmailto: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.orgmailto:cas-user@lists.jasig.org as: richard.wise...@bt.commailto:richard.wise...@bt.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas
[cas-user] Logout redirects
Hi, Can I specify a delay before a logout redirect takes place? I couldn't see anything in the configuration of my server. The reason I ask is that it redirects to the service URL apparently before CAS has had a chance to post the logout XML to the application, so when the redirect completes and the application renders its page, it still believes it's logged in. Thanks, Richard -- 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] Using SHA512
One further (hopefully quick) question, if I may… Until now, I’ve been using the SearchModeSearchDatabaseAuthenticationHandler class, but this doesn’t do everything I need (and neither do the alternatives) so I thought I would copy it and customise it. I’ve given it a new name (of course) but left it in the same package; I’ve compiled it, created a .jar file and put that in WEB-INF/lib (where I’ve successfully put various other .jars to get things working). However, CAS is complaining on start-up: Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'authenticationManager' defined in ServletContext resource [/WEB-INF/deployerConfigContext.xml]: Cannot resolve reference to bean 'primaryAuthenticationHandler' while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'primaryAuthenticationHandler' defined in ServletContext resource [/W EB-INF/deployerConfigContext.xml]: Initialization of bean failed; nested exception is java.lang.NoClassDefFoundError: org/jasig/cas/authentication/principal/ UsernamePasswordCredentials I think this means it either can’t find my class or can’t turn it into a bean. My class is almost identical to SearchModeSearchDatabaseAuthenticationHandler, so the latter seems unlikely. Am I missing a step? Thanks, Richard From: richard.wise...@bt.com [mailto:richard.wise...@bt.com] Sent: 10 July 2014 18:30 To: cas-user@lists.jasig.org Subject: RE: [cas-user] Using SHA512 Thanks again Dmitriy. I suspected that it wouldn't be possible out of the box but thought I'd ask just in case! I'll look into the possibility of creating a custom plug-in or something. I'll look at the documentation again to try and work out the best/simplest approach. Any pointers or hints would if course be welcome! :-) Thanks once again, Richard -Original Message- From: Dmitriy Kopylenko [dkopyle...@unicon.netmailto:dkopyle...@unicon.net] Sent: Thursday, July 10, 2014 04:26 PM GMT Standard Time To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org Subject: Re: [cas-user] Using SHA512 I don’t think CAS’ out of the box password encoder supports salt, etc. cas-addons has a Shiro’s framework based encoder impl which supports salting (only static at this time): https://github.com/Unicon/cas-addons/wiki/Configuring%20ShiroHashServicePasswordEncoder If there is enough interest for dynamic salt config, we could consider it adding it. Or another option, of course is the JIRA against CAS core for the more robust encoder impl(s) to be developed, etc. Best, Dmitriy. On Jul 10, 2014, at 11:19 AM, richard.wise...@bt.commailto:richard.wise...@bt.com wrote: Hi Dmitriy, Thanks very much for that – it works! :-) Now for the really difficult part, I fear… Is it possible to provide a salt by specifying a database column? Thanks again, Richard From: Dmitriy Kopylenko [mailto:dkopyle...@unicon.net] Sent: 10 July 2014 16:12 To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org Subject: Re: [cas-user] Using SHA512 Hi Richard. Try SHA-512 instead of SHA512 Best, Dmitriy. On Jul 10, 2014, at 10:04 AM, Richard Wiseman richard.wise...@bt.commailto:richard.wise...@bt.com wrote: Hi, The CAS documentation https://wiki.jasig.org/display/CASUM/JDBC indicates that you can use any of the MACs listed on the JDK Javadoc http://download.oracle.com/javase/1.5.0/docs/guide/security/jce/JCERefGuide.html#AppA for the password encoder's encodingAlgorithm attribute; this list includes HmacSHA512, which is what I want to use. (I confess I don't know the difference, if any, between SHA512 and HmacSHA512 in the context of hashing passwords.) I have used the following in my deployerConfigContext.xml file: bean id=passwordEncoder class=org.jasig.cas.authentication.handler.DefaultPasswordEncoder c:encodingAlgorithm=SHA1 p:characterEncoding=UTF-8 / and it worked. However, neither of the following two variants works: bean id=passwordEncoder class=org.jasig.cas.authentication.handler.DefaultPasswordEncoder c:encodingAlgorithm=HmacSHA512 p:characterEncoding=UTF-8 / and bean id=passwordEncoder class=org.jasig.cas.authentication.handler.DefaultPasswordEncoder c:encodingAlgorithm=SHA512 p:characterEncoding=UTF-8 / Each of these results in something in the log such as: 2014-07-10 15:13:01,251 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN = WHO: audit:unknown WHAT: java.security.NoSuchAlgorithmException: SHA512 MessageDigest not available ACTION: TICKET_GRANTING_TICKET_NOT_CREATED APPLICATION: CAS WHEN: Thu Jul 10 15:13:01 BST 2014 CLIENT IP ADDRESS: 10.255.240.6 SERVER IP ADDRESS: cas.zion.bt.co.uk = This suggests that I have to provide an implementation of SHA512. However, I
RE: [cas-user] Using SHA512
The password and salt are indeed stored in the same database in different columns. The only encoding I ever seem to see is base64, so the hex actually surprised me! (I've next to no experience with hashing passwords, but my googling has tended to yield results that base64-encode hashes and salts.) As far as ordering of digest inputs goes, that I couldn't say, since it's all done by an Apache Shiro object: Sha512Hash shaHasher = new Sha512Hash(password, salt, iterations); (And the next time shaHasher is mentioned, it's to get the bytes to pass to String.format.) Regards, Richard -Original Message- From: Marvin Addison [mailto:marvin.addi...@gmail.com] Sent: 14 July 2014 15:54 To: cas-user@lists.jasig.org Subject: Re: [cas-user] Using SHA512 An example hash is: 4d8d39a8283a53aeb51061457edc32c6a8e5404864b7571bf7b33d2c3bd5c580869ac1635be0d8ee57581f28b8aa9799729244852eb7aa010e7ac7b1cd69638f And an example salt is: 91f3c641110b2ded640c418046b3cb5af257da06ca98f192085cb10c7443e5e9 I think hex encoding is common and safe to assume generally. Just to clarify, these values are stored in separate columns in the same table? I would hope that's common and a safe assumption. Supporting values across separate tables is possible, but it's hopefully an edge case we could ignore. I also have to be able to specify the number of iterations, of course, which is another issue! That's a common input for salted hashing, so that would be an anticipated configuration point. The only concern you didn't address is whether the salt is the first input to the digest or the last; I have seen both approaches used in practice. I find it strange that there is no standard or guidance on the matter despite having researched it fairly extensively. It looks like it's simply an arbitrary choice and the CAS component would have to support both approaches. M -- You are currently subscribed to cas-user@lists.jasig.org as: richard.wise...@bt.com 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
[cas-user] Using SHA512
Hi, The CAS documentation https://wiki.jasig.org/display/CASUM/JDBC indicates that you can use any of the MACs listed on the JDK Javadoc http://download.oracle.com/javase/1.5.0/docs/guide/security/jce/JCERefGuide.html#AppA for the password encoder's encodingAlgorithm attribute; this list includes HmacSHA512, which is what I want to use. (I confess I don't know the difference, if any, between SHA512 and HmacSHA512 in the context of hashing passwords.) I have used the following in my deployerConfigContext.xml file: bean id=passwordEncoder class=org.jasig.cas.authentication.handler.DefaultPasswordEncoder c:encodingAlgorithm=SHA1 p:characterEncoding=UTF-8 / and it worked. However, neither of the following two variants works: bean id=passwordEncoder class=org.jasig.cas.authentication.handler.DefaultPasswordEncoder c:encodingAlgorithm=HmacSHA512 p:characterEncoding=UTF-8 / and bean id=passwordEncoder class=org.jasig.cas.authentication.handler.DefaultPasswordEncoder c:encodingAlgorithm=SHA512 p:characterEncoding=UTF-8 / Each of these results in something in the log such as: 2014-07-10 15:13:01,251 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN = WHO: audit:unknown WHAT: java.security.NoSuchAlgorithmException: SHA512 MessageDigest not available ACTION: TICKET_GRANTING_TICKET_NOT_CREATED APPLICATION: CAS WHEN: Thu Jul 10 15:13:01 BST 2014 CLIENT IP ADDRESS: 10.255.240.6 SERVER IP ADDRESS: cas.zion.bt.co.uk = This suggests that I have to provide an implementation of SHA512. However, I have no idea where to get one or how to make it available once I do! (I assume I would get a JAR file and put it in WEB-INF/lib - but I don't know how I would specify the implementing class name in deployerConfigContext.xml.) Also, even if I do find an implementation, what I really need is one that lets me specify a salt for each password. And I need to get the salt from the database containing the hashed passwords. Is this an unrealistic or naively optimistic notion? Should I really be thinking about implementing a bean or other Java class and (somehow) using that instead of CAS's built in JDBC options? If I should, what's the preferred/easiest approach? Any advice would be much appreciated! Many thanks. -- 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] Using SHA512
Hi Dmitriy, Thanks very much for that - it works! :-) Now for the really difficult part, I fear... Is it possible to provide a salt by specifying a database column? Thanks again, Richard From: Dmitriy Kopylenko [mailto:dkopyle...@unicon.net] Sent: 10 July 2014 16:12 To: cas-user@lists.jasig.org Subject: Re: [cas-user] Using SHA512 Hi Richard. Try SHA-512 instead of SHA512 Best, Dmitriy. On Jul 10, 2014, at 10:04 AM, Richard Wiseman richard.wise...@bt.commailto:richard.wise...@bt.com wrote: Hi, The CAS documentation https://wiki.jasig.org/display/CASUM/JDBC indicates that you can use any of the MACs listed on the JDK Javadoc http://download.oracle.com/javase/1.5.0/docs/guide/security/jce/JCERefGuide.html#AppA for the password encoder's encodingAlgorithm attribute; this list includes HmacSHA512, which is what I want to use. (I confess I don't know the difference, if any, between SHA512 and HmacSHA512 in the context of hashing passwords.) I have used the following in my deployerConfigContext.xml file: bean id=passwordEncoder class=org.jasig.cas.authentication.handler.DefaultPasswordEncoder c:encodingAlgorithm=SHA1 p:characterEncoding=UTF-8 / and it worked. However, neither of the following two variants works: bean id=passwordEncoder class=org.jasig.cas.authentication.handler.DefaultPasswordEncoder c:encodingAlgorithm=HmacSHA512 p:characterEncoding=UTF-8 / and bean id=passwordEncoder class=org.jasig.cas.authentication.handler.DefaultPasswordEncoder c:encodingAlgorithm=SHA512 p:characterEncoding=UTF-8 / Each of these results in something in the log such as: 2014-07-10 15:13:01,251 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN = WHO: audit:unknown WHAT: java.security.NoSuchAlgorithmException: SHA512 MessageDigest not available ACTION: TICKET_GRANTING_TICKET_NOT_CREATED APPLICATION: CAS WHEN: Thu Jul 10 15:13:01 BST 2014 CLIENT IP ADDRESS: 10.255.240.6 SERVER IP ADDRESS: cas.zion.bt.co.uk = This suggests that I have to provide an implementation of SHA512. However, I have no idea where to get one or how to make it available once I do! (I assume I would get a JAR file and put it in WEB-INF/lib - but I don't know how I would specify the implementing class name in deployerConfigContext.xml.) Also, even if I do find an implementation, what I really need is one that lets me specify a salt for each password. And I need to get the salt from the database containing the hashed passwords. Is this an unrealistic or naively optimistic notion? Should I really be thinking about implementing a bean or other Java class and (somehow) using that instead of CAS's built in JDBC options? If I should, what's the preferred/easiest approach? Any advice would be much appreciated! Many thanks. -- You are currently subscribed to cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org as: dkopyle...@unicon.netmailto: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.orgmailto:cas-user@lists.jasig.org as: richard.wise...@bt.commailto:richard.wise...@bt.com 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] Using SHA512
Thanks again Dmitriy. I suspected that it wouldn't be possible out of the box but thought I'd ask just in case! I'll look into the possibility of creating a custom plug-in or something. I'll look at the documentation again to try and work out the best/simplest approach. Any pointers or hints would if course be welcome! :-) Thanks once again, Richard -Original Message- From: Dmitriy Kopylenko [dkopyle...@unicon.netmailto:dkopyle...@unicon.net] Sent: Thursday, July 10, 2014 04:26 PM GMT Standard Time To: cas-user@lists.jasig.org Subject: Re: [cas-user] Using SHA512 I don’t think CAS’ out of the box password encoder supports salt, etc. cas-addons has a Shiro’s framework based encoder impl which supports salting (only static at this time): https://github.com/Unicon/cas-addons/wiki/Configuring%20ShiroHashServicePasswordEncoder If there is enough interest for dynamic salt config, we could consider it adding it. Or another option, of course is the JIRA against CAS core for the more robust encoder impl(s) to be developed, etc. Best, Dmitriy. On Jul 10, 2014, at 11:19 AM, richard.wise...@bt.commailto:richard.wise...@bt.com wrote: Hi Dmitriy, Thanks very much for that – it works! :-) Now for the really difficult part, I fear… Is it possible to provide a salt by specifying a database column? Thanks again, Richard From: Dmitriy Kopylenko [mailto:dkopyle...@unicon.net] Sent: 10 July 2014 16:12 To: cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org Subject: Re: [cas-user] Using SHA512 Hi Richard. Try SHA-512 instead of SHA512 Best, Dmitriy. On Jul 10, 2014, at 10:04 AM, Richard Wiseman richard.wise...@bt.commailto:richard.wise...@bt.com wrote: Hi, The CAS documentation https://wiki.jasig.org/display/CASUM/JDBC indicates that you can use any of the MACs listed on the JDK Javadoc http://download.oracle.com/javase/1.5.0/docs/guide/security/jce/JCERefGuide.html#AppA for the password encoder's encodingAlgorithm attribute; this list includes HmacSHA512, which is what I want to use. (I confess I don't know the difference, if any, between SHA512 and HmacSHA512 in the context of hashing passwords.) I have used the following in my deployerConfigContext.xml file: bean id=passwordEncoder class=org.jasig.cas.authentication.handler.DefaultPasswordEncoder c:encodingAlgorithm=SHA1 p:characterEncoding=UTF-8 / and it worked. However, neither of the following two variants works: bean id=passwordEncoder class=org.jasig.cas.authentication.handler.DefaultPasswordEncoder c:encodingAlgorithm=HmacSHA512 p:characterEncoding=UTF-8 / and bean id=passwordEncoder class=org.jasig.cas.authentication.handler.DefaultPasswordEncoder c:encodingAlgorithm=SHA512 p:characterEncoding=UTF-8 / Each of these results in something in the log such as: 2014-07-10 15:13:01,251 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN = WHO: audit:unknown WHAT: java.security.NoSuchAlgorithmException: SHA512 MessageDigest not available ACTION: TICKET_GRANTING_TICKET_NOT_CREATED APPLICATION: CAS WHEN: Thu Jul 10 15:13:01 BST 2014 CLIENT IP ADDRESS: 10.255.240.6 SERVER IP ADDRESS: cas.zion.bt.co.uk = This suggests that I have to provide an implementation of SHA512. However, I have no idea where to get one or how to make it available once I do! (I assume I would get a JAR file and put it in WEB-INF/lib - but I don't know how I would specify the implementing class name in deployerConfigContext.xml.) Also, even if I do find an implementation, what I really need is one that lets me specify a salt for each password. And I need to get the salt from the database containing the hashed passwords. Is this an unrealistic or naively optimistic notion? Should I really be thinking about implementing a bean or other Java class and (somehow) using that instead of CAS's built in JDBC options? If I should, what's the preferred/easiest approach? Any advice would be much appreciated! Many thanks. -- You are currently subscribed to cas-user@lists.jasig.orgmailto:cas-user@lists.jasig.org as: dkopyle...@unicon.netmailto: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.orgmailto:cas-user@lists.jasig.org as: richard.wise...@bt.commailto:richard.wise...@bt.com 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.orgmailto:cas-user@lists.jasig.org as: dkopyle...@unicon.netmailto: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: richard.wise...@bt.com
