Re: Re:[cas-user] Problem with JPA ticket Registry

[Damiano Biagioli]

Thanks Geoffrey for your reply. Which  problems did you came across  exactly 
while using the JpaTicketRegistry ? It would be very useful if you could 
describe them . This way , I could reproduce the deadlocks in order to try to 
avoid them  ( i now have created a test installation running on mysql, our 
production system will be running on oracle ).


Thanks for any help,

Damiano



Da: Whittaker, Geoffrey 
Inviato: martedì 28 luglio 2015 16.52
A: cas-user@lists.jasig.org
Oggetto: RE: Re:[cas-user] Problem with JPA ticket Registry


For what it's worth, I had lots of issues with JPA using MSSQL as the backend 
for my CAS4 cluster.  We got lots of deadlocks that would frequently take the 
system offline.  I was never able to fully solve that.



Finally, we went to ehcache for the ticket registries and while it's not 
persistent, I rarely if ever have to drop all the servers at once anyway.  It 
took a little tuning, but is working fine for us now.



Geoff



From: Damiano Biagioli [mailto:d.biagi...@esc2.it]
Sent: Wednesday, July 22, 2015 3:02 AM
To: cas-user@lists.jasig.org
Subject: Re: Re:[cas-user] Problem with JPA ticket Registry



Thanks for the reply! Do you have any documentation about the  configuration of 
 redis and CAS ?



Damiano



Da: ?? mailto:wei...@opark.com>>
Inviato: mercoledì 22 luglio 2015 03.32
A: cas-user@lists.jasig.org
Oggetto: Re:[cas-user] Problem with JPA ticket Registry



I'm using a Redis server for TicketRegistry.





-- Original --

From:  "Damiano Biagioli"mailto:d.biagi...@esc2.it>>;

Date:  Tue, Jul 21, 2015 06:17 PM

To:  "cas-user"mailto:cas-user@lists.jasig.org>>;

Subject:  [cas-user] Problem with JPA ticket Registry



Hello Everyone,

First , i'd like to thank  Stephan Arts  for his answers to my previous 
questions  . I'm trying to create a clustered CAS deployment; therefore ,  all 
the nodes in the CAS cluster  need to  access the ticket present in the 
ticketRegistry  . In order to achieve that objective , i' m trying to use a 
JpaTicketRegistry as a shared ticket Registry betwwen the CAS cluster nodes  
.Do you think it would be better to use EhCache or MemCached instead? I've come 
across a weird (i think) problem on a single node test installation of a CAS 
using JPATicketRegistry : the TGT are generated but they are not inserted in 
the database , that  is ,in the hibernate logs  (that are written inside the 
cas log ) , there are no "insert" , just "select" after a TGT is created . Am i 
missing something ? i see no errors in the CAS logs  I' m attaching my 
ticketRegistry.xml file (without passwords) and  some CAS logs  ... i've found 
that other people have come across the same problem in the past :



https://groups.google.com/forum/#!topic/jasig-cas-user/lk2cY4TejIg

that  is , TGTs are created but are not inserted in the DB ...





Thanks for any help,

Sorry for my poor english ,

Damiano

--

You are currently subscribed to 
cas-user@lists.jasig.org as: 
wei...@opark.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: 
d.biagi...@esc2.it

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: 
geoff.whitta...@unf.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] Drop the management webapp

[Linda Toth]

Unfortunately, we are still at 3.4.2 and have frequent additions to the CAS
registry - however, we could insert them via the Database until moving to
the JSON registry .. honestly, by the time I find a way to migrate our
unusual authentication policies from this version to even 3.5.2, you all
will have a different solution anyhow.  We can adjust.

Linda

Linda Toth
University of Alaska - Office of Information Technology (OIT) - Identity
and Access Management
910 Yukon Drive, Suite 103
Fairbanks, Alaska 99775
Tel: 907-450-8320
Fax: 907-450-8381
linda.t...@alaska.edu | www.alaska.edu/oit/


On Mon, Jul 27, 2015 at 5:34 AM, Jérôme LELEU  wrote:

> Hi,
>
> It's already possible to reload the services periodically from database
> for example, but not when it's defined in the Spring context.
>
> With the new JSON services registry, the services are automatically
> created, updated and deleted.
>
> Best regards,
> Jérôme
>
>
> 2015-07-27 15:20 GMT+02:00 Ourada, John :
>
>>  Ours changes very infrequently also, but has started changing more now
>> that we have external apps that need to authenticate.  Those require a
>> manual entry in the deployer config file.  It requires a manual restart of
>> CAS application to reload them.  I haven’t looked at 4.1 yet, but it would
>> be nice if the app would look for updated service registry files and
>> reloaded them periodically.
>>
>>
>>
>> -john
>>
>>
>>
>> *From:* Christopher Myers [mailto:cmy...@mail.millikin.edu]
>> *Sent:* Monday, July 27, 2015 7:16 AM
>> *To:* cas-user@lists.jasig.org
>> *Subject:* Re: [cas-user] Drop the management webapp
>>
>>
>>
>> Honestly, our CAS configuration changes so infrequently that we don't
>> even need to use a regular service registry; we just have our configs
>> stored in the deployerConfigContext.xml file directly.
>>
>>
>> Chris
>>
>>
>> >>> Jérôme LELEU 07/26/15 9:08 AM >>>
>>
>> Hi,
>>
>>
>>
>> The CAS service model has strongly evolved for the CAS server v4.1 and
>> the powerful new policies are hard to define through a UI. Maintining this
>> webapp requires a lot of work.
>>
>> The default services registry is now based on JSON files which also makes
>> manual editing a lot easier.
>>
>>
>>
>> I'm in favor of dropping the CAS management webapp or maybe first moving
>> it into a separate project.
>>
>>
>>
>> I'd like to get feedbacks on this idea: do CAS deployers use it? How?
>>
>>
>>
>> Thanks.
>>
>> Best regards,
>>
>> Jérôme
>>
>>
>>
>> --
>> You are currently subscribed to cas-user@lists.jasig.org as: 
>> cmy...@mail.millikin.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: 
>> jour...@depaul.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: lel...@gmail.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: ltt...@alaska.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

[cas-user] TCC Application Developer – Portal Administrator Position Posted

[Fountain, Rebecca]

[cid:image001.jpg@01CFF520.B31BB5D0]





Good afternoon,

We’re hoping you might know someone who would be an excellent fit as the new 
Application Developer – Portal Administrator at Tacoma Community College. The 
Developer plans, designs, implements, develops and maintains customer software 
applications in an n-tiered, Microsoft networking environment. If you know 
someone with a passion for technology, we’d love to hear from you.

TCC is a comprehensive community college located in the beautiful Pacific 
Northwest, just 35 miles south of Seattle. We are a diverse, creative, and 
engaging institution - recognized nationally as an Achieving the Dream “Leader 
College.” The Tacoma-Pierce County area, located on beautiful Puget Sound and 
framed by the Cascade and Olympic mountain ranges, offer residents and visitors 
a wealth of cultural and recreational opportunities.

[cid:image005.png@01D0C9E4.7D986450]To
 view the complete position details and to apply,
please visit  http://www.tacomacc.edu/abouttcc/employment/

TCC is an Equal Opportunity Employer and Educator




Christine Nicolai
Support Assistant, Human Resources
Tacoma Community College
6501 South 19th Street
Tacoma, WA 98466
(253) 566-6043



-- 
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

image004.wmz
Description: image004.wmz

RE: [cas-user] Attribute repository with multiple different sources

[Whittaker, Geoffrey]

So, I've been playing with this for a few hours now and I was wondering if
someone could share some insights.  

The documentation on github says to use a large blob of beans and I was
reviewing the persondir docs and it seems much simpler on theirs.  I was
wondering is the caching of the merged attributes necessary?  I mean,
they're cached already in the TGT, right?Also, I keep running into odd
dependency requirements when I try to implement as shown in github.  Does
anyone have a working template they can share with me?

>From github:



























-Original Message-
From: Whittaker, Geoffrey [mailto:geoff.whitta...@unf.edu] 
Sent: Tuesday, July 28, 2015 10:54 AM
To: cas-user@lists.jasig.org
Subject: RE: [cas-user] Attribute repository with multiple different sources

Thanks Tom.  

That looks like just the ticket (pardon the pun).  Hopefully, I can
incorporate that without too much trouble.

Geoff 

-Original Message-
From: Tom O'Neill [mailto:one...@sigcorp.com] 
Sent: Tuesday, July 28, 2015 10:41 AM
To: cas-user@lists.jasig.org
Subject: RE: [cas-user] Attribute repository with multiple different sources

Geoff,

In the past with CAS 3.5.x I've used a merging attribute repository to
implement the behavior you are describing.
Each attribute repository can have its own search filter and there are
multiple strategies for how merging occurs when the attribute is available
from both sources.
The options for attribute release in CAS 4 are outlined in the github hosted
documentation:
http://jasig.github.io/cas/4.0.x/integration/Attribute-Release.html

Hopefully that helps!

Thanks,

    Tom O'Neill
    Senior Consultant
    Strata Information Group

-Original Message-
From: Whittaker, Geoffrey [mailto:geoff.whitta...@unf.edu]
Sent: Monday, July 27, 2015 11:20 AM
To: cas-user@lists.jasig.org
Subject: RE: [cas-user] Attribute repository with multiple different sources

I'd thought of that, but was worried how cas might react.  I'll do a test
build of that and see what happens.  I'm Also looking at the possibility of
adding the CN field to the second LDAP source.  

Geoff 

-Original Message-
From: Waldbieser, Carl [mailto:waldb...@lafayette.edu]
Sent: Monday, July 27, 2015 9:23 AM
To: cas-user@lists.jasig.org
Subject: Re: [cas-user] Attribute repository with multiple different sources

Geoffrey,

Can you just map both 'uid' and 'cn' to 'UDC_IDENTIFIER'?  I could see a
potential issue with that if one directory supports both attributes and
there would be some potential ambiguity about which attribute would actually
end up being mapped.

I am guessing there is likely to be a solution to this baked into CAS.

You can also handle this by manipulating the LDAP response before it reaches
CAS with an LDAP proxy.  Specifically, you could convert the 'cn' attribute
in the response of LDAP2 to 'uid'.
I wrote a blurb on setting up an LDAP proxy [1], though I am just noticing
that my code formatting was messed up.  A well-formatted code example can be
found on github[2].
This is a more heavy-handed approach, so I'd probably try experimenting with
CAS attribute mappings first.
  

Thanks,
Carl Waldbieser

[1] https://lifeonlayer7.wordpress.com/2015/07/18/ldap-proxy/
[2]
https://github.com/twisted/ldaptor/blob/master/docs/source/cookbook/ldap-pro
xy.rst

- Original Message -
From: "Geoffrey Whittaker" 
To: cas-user@lists.jasig.org
Sent: Monday, July 27, 2015 7:36:19 AM
Subject: [cas-user] Attribute repository with multiple different sources

I have CAS4 with two LDAP Auth Handlers.  The first is pointed at my local
Active Directory (LDAP1) which has my Employees, Staff, Faculty, etc..  The
second is pointed at another LDAP server (ldap2) which contains alumni,
parents, and other 'special' people.  

 

Currently, if the search of LDAP1 fails CAS falls through to LDAP2.  In the
past, it's been sufficient for those people only in LDAP2 to merely
authenticate.  Now, I need to get an attribute from that directory and map
it to the attribute map to the same field that LDAP1 would use.  The problem
is the name of the fields is different.  In LDAP1 the field is 'cn' in LDAP2
the field is 'uid'.  I somehow have to get that value from into a custom
Attribute field we called UDC_IDENTIFIER regardless of the directory.

 

Can I have more than one attribute repository, and if can someone point to
an example config?

 

 

 

Am I making this too complicated?  Is there another way to handle this?  

 

Thanks


--
You are currently subscribed to cas-user@lists.jasig.org as:
geoff.whitta...@unf.edu To unsubscribe, change settings or

RE: [cas-user] Attribute repository with multiple different sources

[Misagh Moayyed]

Attributes are cached in the TGT, yes. The caching of merged attributes is
not required; it only comes into play when you logout and destroy your TGT
and attempt to log back in, at which time depending on persondir cache
configuration, the repository may not be contacted because it already has
cached copies of the attributes. So things will go faster, if the
attribute-fetching process from the repository is a resource-expensive
operation.

I suppose, the most comprehensive example is what uPortal does today with
persondir:
https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/resource
s/properties/contexts/personDirectoryContext.xml

Note that a side-effect of caching attributes in the TGT is that they will
not change during the lifetime of a TGT; so if you decided to change an
attribute from X to Y, at this point, the only way to recognize that
change is to ask the user to log out and log back (think attribute-driven
MFA for instance). Future versions of CAS will present a feature to not
require that logout, should you need immediate changes to the attribute
repository.

What sort of odd dependency requirements are you running into?

-Original Message-
From: Whittaker, Geoffrey [mailto:geoff.whitta...@unf.edu]
Sent: Wednesday, July 29, 2015 11:55 AM
To: cas-user@lists.jasig.org
Subject: RE: [cas-user] Attribute repository with multiple different
sources

So, I've been playing with this for a few hours now and I was wondering if
someone could share some insights.

The documentation on github says to use a large blob of beans and I was
reviewing the persondir docs and it seems much simpler on theirs.  I was
wondering is the caching of the merged attributes necessary?  I mean,
they're cached already in the TGT, right?Also, I keep running into odd
dependency requirements when I try to implement as shown in github.  Does
anyone have a working template they can share with me?

>From github:



























-Original Message-
From: Whittaker, Geoffrey [mailto:geoff.whitta...@unf.edu]
Sent: Tuesday, July 28, 2015 10:54 AM
To: cas-user@lists.jasig.org
Subject: RE: [cas-user] Attribute repository with multiple different
sources

Thanks Tom.

That looks like just the ticket (pardon the pun).  Hopefully, I can
incorporate that without too much trouble.

Geoff

-Original Message-
From: Tom O'Neill [mailto:one...@sigcorp.com]
Sent: Tuesday, July 28, 2015 10:41 AM
To: cas-user@lists.jasig.org
Subject: RE: [cas-user] Attribute repository with multiple different
sources

Geoff,

In the past with CAS 3.5.x I've used a merging attribute repository to
implement the behavior you are describing.
Each attribute repository can have its own search filter and there are
multiple strategies for how merging occurs when the attribute is available
from both sources.
The options for attribute release in CAS 4 are outlined in the github
hosted
documentation:

http://jasig.github.io/cas/4.0.x/integration/Attribute-Release.html

Hopefully that helps!

Thanks,

    Tom O'Neill
    Senior Consultant
    Strata Information Group

-Original Message-
From: Whittaker, Geoffrey [mailto:geoff.whitta...@unf.edu]
Sent: Monday, July 27, 2015 11:20 AM
To: cas-user@lists.jasig.org
Subject: RE: [cas-user] Attribute repository with multiple different
sources

I'd thought of that, but was worried how cas might react.  I'll do a test
build of that and see what happens.  I'm Also looking at the possibility
of
adding the CN field to the second LDAP source.

Geoff

-Original Message-
From: Waldbieser, Carl [mailto:waldb...@lafayette.edu]
Sent: Monday, July 27, 2015 9:23 AM
To: cas-user@lists.jasig.org
Subject: Re: [cas-user] Attribute repository with multiple different
sources

Geoffrey,

Can you just map both 'uid' and 'cn' to 'UDC_IDENTIFIER'?  I could see a
potential issue with that if one directory supports both attributes and
there would be some potential ambiguity about which attribute would
actually
end up being mapped.

I am guessing there is likely to be a solution to this baked into CAS.

You can also handle this by manipulating the LDAP response before it
reaches
CAS with an LDAP proxy.  Specifically, you could convert the 'cn'
attribute
in the response of LDAP2 to 'uid'.
I wrote a blurb on setting up an LDAP proxy [1], though I am just noticing
that my code formatting was messed up.  A well-formatted code example can
be
found on github[2].
This is a more heavy-handed approach, so I'd probably try experimenting
with
CAS attribute mappings first.


Thanks,
Carl Waldbieser

[1] https://lifeonlayer7.wordpress.com/2015/07/18/ldap-proxy/
[2]
http