[cas-user] PropertyPlaceholderConfigurer for host.name
Andrew Morgan
I'm trying to set the value of the host.name parameter, which is normally
in WEB-INF/cas.properties, from an external file. I created a file
/etc/cas/dev.properties which contains:
host.name=login1
Then I added the following to the bottom of
WEB-INF/deployerConfigContext.xml:
<!-- pull in some properties from an external file -->
<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list>
<value>file:/etc/cas/dev.properties</value>
</list>
</property>
</bean>
However, when I deploy the WAR, I get the following error:
2011-06-24 16:38:03,830 FATAL
[org.jasig.cas.web.init.SafeContextLoaderListener] -
SafeContextLoaderListener:
The Spring ContextLoaderListener we wrap threw on contextInitialized.
But for our having caught this error, the web application context would
not have initialized.
org.springframework.beans.factory.BeanDefinitionStoreException: Invalid
bean definition with name 'ticketGrantingTicketUniqueIdGenerator' defined
in ServletContext resource
[/WEB-INF/spring-configuration/uniqueIdGenerators.xml]: Could not resolve
placeholder 'host.name'
at
org.springframework.beans.factory.config.PropertyPlaceholderConfigurer.processProperties(PropertyPlaceholderConfigurer.java:268)
at
org.springframework.beans.factory.config.PropertyResourceConfigurer.postProcessBeanFactory(PropertyResourceConfigurer.java:75)
at
org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:553)
at
org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:527)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:362)
at
org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255)
...
I have searched for a while, but I can't figure out why this doesn't work.
Any suggestions?
Thanks,
Andy
--
You are currently subscribed to cas-...@lists.jasig.org as: jasig-cas-user...@googlegroups.com
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
Scott Battaglia
--
You are currently subscribed to cas-...@lists.jasig.org as: scott.b...@gmail.com
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
James Parry
Hi All,
I’m after some guidance brief guidance as to if anyone has done anything like the following.
We’ve had a request to only allow a user to be logged in once. Meaning that if they logs in a second time it invalidates to first logon kicking them out of the system.
I was wondering if anyone else in the community has adapted Cas to work in this manner or is this feature already supported and I’ve just missed.
I’m using 2 clustered Cas (Tomcat Session/ JPA ticket reg) to allow users to authenticate for our own single web application that distributed over about 12 servers with Load balanacer stick sessions to stick a user to a single server.
My main question is would this sort of thing even be possible within Cas or is it completely infeasible.
I’m assuming that Service Tickets will just need to be validated far more regularly (not just at the start of the users session on a server) to be able to invalidate the initial users tickets. And ensure that if the user logs in a second time i invalidate the original ticket. Would this approach work or am I completely off base?
Many Thanks for any replys. Eagerly awaiting anyone’s input.
James Parry
__________ Information from ESET NOD32 Antivirus, version of virus signature database 6243 (20110627) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
Andrew Morgan
PropertyPlaceholderConfigurer already.
I was able to get this to work by modifying cas-servlet.xml:
<bean id="casPropertyPlaceholderConfigurer2"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"
p:location="file:/etc/cas/dev.properties" />
and modifying spring-configuration/propertyFileConfigurer.xml:
<bean id="propertyPlaceholderConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"
p:location="file:/etc/cas/dev.properties" />
Thanks for the clue!
Andy
On Sun, 26 Jun 2011, Scott Battaglia wrote:
> There are multiple ApplicationContext loaders and certain properties aren't
> available between contexts (i.e. if you look at 3.3.5's version of the
> Spring config files it loads the cas.properties twice. Newer versions both
> just import the same bean from an external file to solve the problem. My
> guess is you are running into the context problem.
>
>
> On Fri, Jun 24, 2011 at 7:42 PM, Andrew Morgan <mor...@orst.edu> wrote:
>
>> CAS version: 3.3.5
>>
>> I'm trying to set the value of the host.name parameter, which is normally
>> in WEB-INF/cas.properties, from an external file. I created a file
>> /etc/cas/dev.properties which contains:
>>
>> host.name=login1
>>
>> Then I added the following to the bottom of WEB-INF/deployerConfigContext.
>> **xml:
>>
>> <!-- pull in some properties from an external file -->
>> <bean id="propertyConfigurer" class="org.springframework.**
>> beans.factory.config.**PropertyPlaceholderConfigurer"**>
>> <property name="locations">
>> <list>
>> <value>file:/etc/cas/dev.**properties</value>
>> </list>
>> </property>
>> </bean>
>>
>> However, when I deploy the WAR, I get the following error:
>>
>> 2011-06-24 16:38:03,830 FATAL [org.jasig.cas.web.init.**SafeContextLoaderListener]
>> - SafeContextLoaderListener:
>> The Spring ContextLoaderListener we wrap threw on contextInitialized.
>> But for our having caught this error, the web application context would not
>> have initialized.
>> org.springframework.beans.**factory.**BeanDefinitionStoreException:
>> Invalid bean definition with name '**ticketGrantingTicketUniqueIdGe**nerator'
>> defined in ServletContext resource [/WEB-INF/spring-**configuration/**uniqueIdGenerators.xml]:
>> Could not resolve placeholder 'host.name'
>> at org.springframework.beans.**factory.config.**
>> PropertyPlaceholderConfigurer.**processProperties(**
>> PropertyPlaceholderConfigurer.**java:268)
>> at org.springframework.beans.**factory.config.**
>> PropertyResourceConfigurer.**postProcessBeanFactory(**
>> PropertyResourceConfigurer.**java:75)
>> at org.springframework.context.**support.**
>> AbstractApplicationContext.**invokeBeanFactoryPostProcessor**
>> s(AbstractApplicationContext.**java:553)
>> at org.springframework.context.**support.**
>> AbstractApplicationContext.**invokeBeanFactoryPostProcessor**
>> s(AbstractApplicationContext.**java:527)
>> at org.springframework.context.**support.**
>> AbstractApplicationContext.**refresh(**AbstractApplicationContext.**
>> java:362)
>> at org.springframework.web.**context.ContextLoader.**
>> createWebApplicationContext(**ContextLoader.java:255)
>>
>> ...
>>
>>
>> I have searched for a while, but I can't figure out why this doesn't work.
>> Any suggestions?
>>
>> Thanks,
>> Andy
>>
>> --
>> You are currently subscribed to cas-...@lists.jasig.org as:
>> scott.b...@gmail.com
>> To unsubscribe, change settings or access archives, see
>> http://www.ja-sig.org/wiki/**display/JSG/cas-user<http://www.ja-sig.org/wiki/display/JSG/cas-user>
>>
>
> --
> You are currently subscribed to cas-...@lists.jasig.org as: mor...@orst.edu
William G. Thompson, Jr.
> Hi All,
>
>
>
> I’m after some guidance brief guidance as to if anyone has done anything
> like the following.
>
>
>
> We’ve had a request to only allow a user to be logged in once. Meaning that
> if they logs in a second time it invalidates to first logon kicking them out
> of the system.
In order to achieve this behavior you'll have to deal with the
application sessions. Your app would have to detect the second login
was from the same user and somehow invalidate the previous application
session. This has little to do with CAS per se. And sounds like it
would be difficult to implement given your architecture.
>
> I was wondering if anyone else in the community has adapted Cas to work in
> this manner or is this feature already supported and I’ve just missed.
Not that I know of.
You could modify CAS server to detect a second login, kill the
previous TGT and initiate the Single Logout flow based on the initial
TGT. Not sure if that all lines up though with the current CAS code
base, it may take some deep CAS mods. And you'd still have to
application session addressibility issue for SLO to work.
Best,
Bill
>
>
>
> I’m using 2 clustered Cas (Tomcat Session/ JPA ticket reg) to allow users
> to authenticate for our own single web application that distributed over
> about 12 servers with Load balanacer stick sessions to stick a user to a
> single server.
>
>
>
> My main question is would this sort of thing even be possible within Cas or
> is it completely infeasible.
>
> I’m assuming that Service Tickets will just need to be validated far more
> regularly (not just at the start of the users session on a server) to be
> able to invalidate the initial users tickets. And ensure that if the user
> logs in a second time i invalidate the original ticket. Would this approach
> work or am I completely off base?
>
>
>
> Many Thanks for any replys. Eagerly awaiting anyone’s input.
>
>
>
> James Parry
>
>
>
>
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature
> database 6243 (20110627) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
> --
> You are currently subscribed to cas-...@lists.jasig.org as:
James Parry
After a bit more research it I looks like concurrent session control seems to do what I'm trying to achieve.
But due to the way we have our app is deployed (without persistent sessions) it looks like it will be almost impossible to include within our application.
Also im guessing If this was added to the Cas server this wouldn't work as it look for HTTPSessions and won't take account for TGT.
It looks like your idea of adjusting the logon flow to take account of existing TGT and then invalidate them seems the best approach.
Would i need to work out what services tickets are valid for each server or would the single sign-out do that for me?
Any idea where I should look to get more details on how the single sign out actually works. To work out what i need to change/recreate.
Thanks for your time.
James Parry
Best,
Bill
--
You are currently subscribed to cas-...@lists.jasig.org as: james...@meganexus.com
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
__________ Information from ESET NOD32 Antivirus, version of virus signature database 6245 (20110627) __________
The message was checked by ESET NOD32 Antivirus.
__________ Information from ESET NOD32 Antivirus, version of virus signature database 6247 (20110628) __________
The message was checked by ESET NOD32 Antivirus.
__________ Information from ESET NOD32 Antivirus, version of virus signature database 6248 (20110628) __________
The message was checked by ESET NOD32 Antivirus.
__________ Information from ESET NOD32 Antivirus, version of virus signature database 6249 (20110629) __________
The message was checked by ESET NOD32 Antivirus.
__________ Information from ESET NOD32 Antivirus, version of virus signature database 6249 (20110629) __________
The message was checked by ESET NOD32 Antivirus.
--
Marvin Addison
Destorying the user's TGT is all you need to do; this triggers
invalidation of existing service tickets and issues the single
sign-out calls to services visited during the SSO session.
> Any idea where I should look to get more details on how the single sign out actually works.
Study the source of the following classes:
- CentralAuthenticationServiceImpl (destroyTicketGrantingTicket)
- AbstractWebApplicationService (logOutOfService)
- HttpClient
M
James Parry
Almost have it working, so many, many thanks.
One last question. I'm using JPA for Ticket Registry, is there anyway to
identify what tickets belong to whom.
I.E I want to retrieve all tickets that are related by a username. So i
can invalidate them.
However it looks like this data is located within the Authentication
Object thats serialized.
Due to the amount of users we anticipate, iterating through all the
tickets with a for loop is not scalable.
I'm thinking of storing the TGT's against the user in LDAP so I can
easily Invalidate them with the TGT id.
Are there any other options indeed of this?
James Parry
Specialist Developer
MegaNexus Limited
-----Original Message-----
From: Marvin Addison [mailto:marvin....@gmail.com]
Sent: 29 June 2011 14:32
To: cas-...@lists.jasig.org
Subject: Re: [cas-user] Cas to limit users to a single authenticated
session.
> Would i need to work out what services tickets are valid for each
server or would the single sign-out do that for me?
Destorying the user's TGT is all you need to do; this triggers
invalidation of existing service tickets and issues the single
sign-out calls to services visited during the SSO session.
> Any idea where I should look to get more details on how the single
sign out actually works.
Study the source of the following classes:
- CentralAuthenticationServiceImpl (destroyTicketGrantingTicket)
- AbstractWebApplicationService (logOutOfService)
- HttpClient
M
--
You are currently subscribed to cas-...@lists.jasig.org as:
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
__________ Information from ESET NOD32 Antivirus, version of virus
signature database 6250 (20110629) __________
The message was checked by ESET NOD32 Antivirus.
__________ Information from ESET NOD32 Antivirus, version of virus
signature database 6251 (20110630) __________
The message was checked by ESET NOD32 Antivirus.
__________ Information from ESET NOD32 Antivirus, version of virus
signature database 6252 (20110630) __________
The message was checked by ESET NOD32 Antivirus.
__________ Information from ESET NOD32 Antivirus, version of virus
signature database 6252 (20110630) __________
The message was checked by ESET NOD32 Antivirus.
Marvin Addison
> Object thats serialized.
> Due to the amount of users we anticipate, iterating through all the
> tickets with a for loop is not scalable.
This is a common pain point.
> I'm thinking of storing the TGT's against the user in LDAP so I can
> easily Invalidate them with the TGT id.
> Are there any other options indeed of this?
I would recommend avoiding another system dependency. Let me sketch
out an alternative.
Add a principalId field to TicketGrantingTicketImpl that is annotated
with @Column and populate it in the constructor with the corresponding
field from the Authentication, Authentication#getPrincipal()#getId().
With Hibernate schema creation turned on you should now get a
prinicpalId varchar field in the database on which you can query by
username to look up the TGT and invalidate it.
While the above requires code changes to a core CAS component, it's a
fairly straightforward change that should accommodate your needs in a
natural way.
M
--
James Parry
Marvin,
All working perfectly.. Thank you for all your help.
James Parry
-----Original Message-----
From: Marvin Addison [mailto:marvin....@gmail.com]
Sent: 30 June 2011 15:06
To: cas-...@lists.jasig.org
Subject: Re: [cas-user] Cas to limit users to a single authenticated
session.
M
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
__________ Information from ESET NOD32 Antivirus, version of virus
signature database 6252 (20110630) __________
The message was checked by ESET NOD32 Antivirus.
__________ Information from ESET NOD32 Antivirus, version of virus
signature database 6253 (20110630) __________
The message was checked by ESET NOD32 Antivirus.
__________ Information from ESET NOD32 Antivirus, version of virus
signature database 6253 (20110630) __________
The message was checked by ESET NOD32 Antivirus.