Re: [cas-user] Using httpclient to post to cas as a credential acceptor, but not working

[Andrew Petro]

Hi Richard,

Yes, the value of the Ticket Granting Cookie is the Ticket Granting
Ticket.  The Ticket Granting Cookie is a Cookie for conveying the
Ticket Granting Ticket.

Is the CAS server involved under your control such that you could add
to it support for another means of user authentication, namely an
adhoc trust relationship between your application and CAS such that
your application can assert user identities to CAS?  That would avoid
the password replay approach.

I ran across this code recently, which appears to handily implement
this trusted-applications-can-assert-identities-to-CAS pattern.

https://github.com/epierce/cas-server-extension-token

If you're able to modify the CAS server, you might try implementing that.

Kind regards,

Andrew



On Mon, Oct 15, 2012 at 12:52 AM, Richard Yang  wrote:
> I am still trying to find out a way to use our own login page.
> First of all, I see that using external login UI is on the CAS 3 to do list.
> But when is it going to be implemented?
> We use CAS not for single sign on. But other applocations with we need to
> integrate with has adopted this cas solution.
> After the user logins to our application, I tried to invoke cas login as
> acceptor. I post the username and password plus a randomly generated LT to
> the cas login url, hoping that the cas server will validate the user
> credential (again) without the cas login UI. According to
> http://www.jasig.org/cas/protocol, this should work. I use httpclient to do
> the post. However, the response I got from the post is always the CAS login
> form (which I desperately tried to avoid). It means that the login failed.
> But I don't see why it could fail. If I directly login through  cas login
> page with the same credential, it logged me in.
>
> httpclient code is attached.
>
> The second question is:
> Is the value of cookie CASTGC is the same value as the Ticket granting
> ticket?
>
> Thanks.
>
>
>
>
>
>
>
>
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] service registry database

[Andrew Petro]

Hi Guy,

Sounds like you're conflating persisting the CAS ticket registry (a
temporary cache of CAS-issued tickets) with persisting the service
registry (configuration of which services CAS should allow to use CAS
how).

You can choose to store the ticket registry into a database.  I'd
recommend the default registry implementation (in-memory) or the
EhCache implementation instead.

You can choose to store your service registry in a database.  I'd
suggest considering the JSON registry instead if you don't need write
access through the web-based administrative UI.

Yes, CAS service tickets are normally short-lived.

Yes, service registrations will normally have empty entries in the
rs_attributes (registered service attributes) table.  In a simplest
registration you'll specify zero attributes for CAS to release to the
service.  If you instead specify some, then they'll go in that table.

I won't try to answer the locks table question since I'm not sure I'm
up-to-date on how ticket registry cleaning works in the JPA ticket
registry implementation.  Again, I'd encourage the EhCache ticket
registry instead if you need multi-node access to a shared ticket
registry cache, and the Default implementation (in-memory) if you
don't.  Helps to reduce CAS's runtime dependency on the RDBMS.

Hope this helps,

Andrew



On Thu, Oct 18, 2012 at 4:25 AM, Guy Thomas  wrote:
> I set up a CAS server and two services. I added the persistence of the
> registered services in an Oracle database.
>
>
>
> -  I read somewhere that it’s normal that the serviceticket is so
> short-lived (default: 10 seconds) that its registration in the serviceticket
> table is also short-lived. Is this correct?
>
> -  The locks table has this record: cas-ticket-registry-cleaner
> (application_id, (null) (expiration_date), (null) (unique_id)). Is this OK?
>
> -  The table rs_attributes remains empty: is this normal? What data
> is supposed to be stored in this table?
>
>
>
>
>
>
>
> Guy Thomas
>  [snip]

-- 
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] Can yo manually set CASTGC cookie manually (httpservletrsponse) to a different domain

[Andrew Petro]

Richard,

By design, only CAS can set and read the CAS ticket granting cookie.  This
is important to the security of using CAS, since if your CAS TGC was
readable more widely (by, say, your application on a different domain),
then applications able to read the cookie could read it and use it to craft
their own requests to get service tickets in the name of the user.  That
is, this would enable illicit delegation.

So.  What are you trying to do?  The RESTful API is more intended for your
application to authenticate as itself to get a TGT to obtain STs
authenticating itself to other services.  If you want to be authenticating
end users, then the intent of the CAS design is for your application to
send those users to CAS to log in to CAS directly, obtain a ST to log in to
your application, and then your application can obtain a PGT from that if
you need to be getting PTs to authenticate to other applications on the
user's behalf.

Hope this helps,

Andrew


On Fri, Oct 19, 2012 at 2:46 PM, Richard Yang  wrote:

> I am calling cas Restful API to generate a TGT. I would like to store this
> as the valie in the
> CASTGC. But the domain of my application is different from that of the cas
> server. So can I foul the cas server to make it think this is a valid
> cookie?
>
> Otherwise, I had to generate a ST for each service request
> programmatically using Restful api. This approach has its drawback as it
> involves application code to manage the ST.
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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] Can yo manually set CASTGC cookie manually (httpservletrsponse) to a different domain

[Andrew Petro]

But you probably shouldn't configure the ST to be multiply validatable (as
opposed to just one-time-use).

CAS is an authentication broker, not a session manager.

So, your application (or the end user) can use an ST once to log in to an
application.  Great.  But then that application should establish a
traditional cookie-mediated web application session (for the end user) or
participate in some reasonable web service authentication regime (for
service-to-service calls).

One option would be for the application to itself continue to accept the ST
as a lightweight adhoc session identifier.  Spring Security provides
support for this.  In the case where your application is using this ST to
access a web service directly.

So, yes, you can configure an ST to be longer-lived and multiply-usable, in
CAS ticket expiration policy configuration.  And you probably shouldn't be
needing to do either of those configuration changes.

Hope this helps,

Andrew



On Fri, Oct 19, 2012 at 4:50 PM, Dmitriy Kopylenko <
dmitriy.kopyle...@gmail.com> wrote:

>
>
>
> Is there any way to config cas not to throw away ST. Instead make is valid
> for a period of time?
>
> ** **
>
> Yes, that is possible by configuring serviceTicketExpirationPolicy:
>
>
> https://github.com/Jasig/cas/blob/master/cas-server-webapp/src/main/webapp/WEB-INF/spring-configuration/ticketExpirationPolicies.xml
>
> Cheers,
> Dmitriy.
>
>
> ** **
>
> *From:* Andrew Petro [mailto:ape...@unicon.net]
> *Sent:* Friday, October 19, 2012 2:15 PM
> *To:* cas-user@lists.jasig.org
> *Subject:* Re: [cas-user] Can yo manually set CASTGC cookie manually
> (httpservletrsponse) to a different domain
>
> ** **
>
> Richard,
>
> ** **
>
> By design, only CAS can set and read the CAS ticket granting cookie.  This
> is important to the security of using CAS, since if your CAS TGC was
> readable more widely (by, say, your application on a different domain),
> then applications able to read the cookie could read it and use it to craft
> their own requests to get service tickets in the name of the user.  That
> is, this would enable illicit delegation.
>
> ** **
>
> So.  What are you trying to do?  The RESTful API is more intended for your
> application to authenticate as itself to get a TGT to obtain STs
> authenticating itself to other services.  If you want to be authenticating
> end users, then the intent of the CAS design is for your application to
> send those users to CAS to log in to CAS directly, obtain a ST to log in to
> your application, and then your application can obtain a PGT from that if
> you need to be getting PTs to authenticate to other applications on the
> user's behalf.
>
> ** **
>
> Hope this helps,
>
> ** **
>
> Andrew
>
> ** **
>
> On Fri, Oct 19, 2012 at 2:46 PM, Richard Yang  wrote:***
> *
>
> I am calling cas Restful API to generate a TGT. I would like to store this
> as the valie in the 
>
> CASTGC. But the domain of my application is different from that of the cas
> server. So can I foul the cas server to make it think this is a valid
> cookie?
>
>  
>
> Otherwise, I had to generate a ST for each service request
> programmatically using Restful api. This approach has its drawback as it
> involves application code to manage the ST.
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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.y...@pearson.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: 
> dmitriy.kopyle...@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: ape...@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] Mobile application support

[Andrew Petro]

Juanma,

You might look at uMobile's CAS support as an example.  The uMobile mobile
app, built in the TitaniumAppcelerator framework, is capable of storing the
user's username and password locally, replaying it through CAS login, and
launching web links from the app into browsers pre-provisioned with a
viable TGT single sign-on session token, so that from the experience of the
end user, it "just works".

https://github.com/Jasig/uMobile-app/blob/master/Resources/js/models/login/CASLogin.js,
e.g.

afaik, uMobile isn't doing anything yet with OAuth / Twitter / Facebook /
etc.

Andrew





On Wed, Oct 24, 2012 at 5:21 AM, Juanma  wrote:

> Hi,
>
> The problem is that we are developing a mobile application and we are not
> sure the best way to use CAS.
> We need securize a REST API to be consumed by the mobile application.
>
> Currently we have installed the CAS as a tool for authentication of
> different web applications. We are using authentication by
> username/password and X509, and we plan to use the CAS client support for
> oauth clients (facebook and twitter).
>
> Our goal is to use CAS for mobile users authentication, and  the idea is
> that the user doesn't have to log into each access, and can do login with
> username/password or facebook/twitter (oauth clients).
>
> Has anyone integrated mobile applications with CAS?
>
> Thanks in advanced,
>
> Juanma
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] Turn on ClearPass on 3.5

[Andrew Petro]

Amjad,

That's an interesting point, and may be a use case for a CAS filter
configuration that requires a proxy chain rather than allowing one and also
servicing direct STs.  I'll write that down as something to follow up on in
ClearPass maintenance.

That said, don't let the Adversary use your browser session while you're
logged in to CAS. :)

Kind regards,

Andrew


On Mon, Oct 29, 2012 at 11:41 PM, Amjad Al-Saraireh wrote:

> Then how can I protect my password, suppose that any one access the
> clearpas from my browser he will see it.
> how can I hide it.
>
> Amjad
>
> --
> From: mmoay...@unicon.net
> To: cas-user@lists.jasig.org
> Subject: RE: [cas-user] Turn on ClearPass on 3.5
> Date: Mon, 29 Oct 2012 17:01:12 -0700
>
> What you see is the appropriate correct response. The view is just
> rendering the xml for you. If you see the password on screen, clearpass is
> correctly turned on.
>
>
>
> *-*Misagh*
>
> *
>
>
>
> *From:* Amjad Al-Saraireh [mailto:amjad...@hotmail.com]
> *Sent:* Monday, October 29, 2012 7:43 AM
> *To:* cas-user@lists.jasig.org
> *Subject:* [cas-user] Turn on ClearPass on 3.5
>
>
>
> Hi every one,
>
> Did some body try to enable ClearPass on 3.5.
> We enable it but when we try to access clearPass URL he redirect me to cas
> login page.
> Also when we logged in to CAS and try to access clearPass URL we see the
> actual password not the following code.
>
>
> 
>
> 
>
> actual_password
>
> 
>
> 
>
>
> I folow all the instruction on clearpass Wiki
> https://wiki.jasig.org/display/CASUM/ClearPass
>
> Any body have the same issue or he can guide me.
>
>
>
> Thanks in Advance
>
> Amjad
>
> --
> 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: 
> amjad...@hotmail.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: ape...@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] Cloud App: Java Client for Multiple CAS Installations

[Andrew Petro]

Hi Leif,

The Java CAS Client isn't currently designed to support multiple CAS
servers simultaneously, so you're going to end up writing custom code for
your use case unless you can accept declaring and configuring instances of
the existing library multiply and differently for different per-customer
paths, which as you point out has some scaling problems.

You might choose to live with those known problems.  You will, after all,
have to maintain this per-client configuration somewhere.  Strictly
speaking, you don't have to maintain the current configuration in web.xml
-- you can wire up the CAS ticket validation components using Spring
instead, or even make use of Spring Security's or Apache Shiro's CAS
support.

The login URLs differing per-customer aren't the hardest part of this
integration problem.  That's just a UI consideration in terms of where to
redirect the request for authentication, and indeed you could be putting a
link to that URL in whatever per-client login experience you're providing
in your expense reporting application and avoiding configuring a login URL
into CAS-related Java objects entirely.  Depends on details of the CAS
login user experience you're providing.

Rather, the hardest part of this problem is in knowing, on the redirect
back from CAS, which CAS server configuration to use to validate the
presented service ticket, and in getting the service ticket validation
machinery to use that correct-for-this-customer CAS server.  You might
trigger that off a request parameter (with custom code) or off a specific
per-customer path (suitable for mapping in web.xml, and thus avoiding
customization to the Java CAS Client.)

Anyway.  If you do end up customizing the Java CAS Client to support
multiple CAS servers at once, I do hope you'll share the customizations.
 They might be of interest to other CAS-supporting SaaS providers, and
indeed you might find willing collaborators on making these extensions.

Kind regards,

Andrew

PS: Nice postcards.  http://www.chromeriver.com/postcards/

On Tue, Oct 30, 2012 at 2:21 PM, Leif Bennett
wrote:

> Hi!
>
> Our company provides a software service (expense reports) to multiple
> customer organizations. We handle authentication several ways, and are
> adding CAS for a particular customer. The Java client looks to work well
> for this first customer, but we expect to have more CAS customers in the
> future. Each of these would have their own independent CAS server.
>
> What's the right way to handle the situation where an application needs to
> authenticate using CAS, but the CAS server login URL can be different for
> each login attempt? We'd like to use the Java client if possible, with as
> few modifications as possible. But we don't want to add a different filter
> chain and login URL to web.xml for each customer; that doesn't scale
> acceptably.
>
> I'd thought of having the servlet and filters configured to handle a
> wildcarded URL, with the wildcarded part of the URI giving the customer
> name; that would let a modified filter look up the correct server login URL
> for this login. But the final keyword on doFilter() and non-dynamic server
> login URL combine to prevent us from extending the existing filters. Is
> there a better way than making our own slightly modified copy of them?
>
> I've looked over the docs and archives without finding a better answer.
>
> Leif Bennett
> Chrome River Technologies
> http://www.chromeriver.com
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] doc about initial set-up

[Andrew Petro]

Hi Guy,

Congratulations on your set-up of a CAS server.

Sharing your documentation is a fine way to contribute and to ease the path
for others.  I encourage you to share your documentation.

There are many common casual ways to ease into sharing notes and
documentation about CAS.  For instance, you could
* create an account at wiki.jasig.org and share your document via your
personal wiki space.  This makes your documentation available on the Web
and even discoverable from within Jasig's wiki.
* Put your documentation into a Google Document, set permissions
appropriately broadly upon it, and post a link to that document on this
list.  That's got some interesting collaboration potential and is a format
more like what it sounds like you've currently got.
* Blog somewhere you're comfortable, and post a link to that to this list.

There are also more formal and directly-within-the-project ways to
contribute to documentation.  You might offer edits to the wiki
documentation or the documentation in source control and included in the
CAS server software distribution, for instance.

All the ways of contributing are valuable.  A lot of the value is in
sharing at all, so I do hope I'll have a chance to read over your document.

Congratulations on your CAS server implementation and on your
customizations.

Kind regards,

Andrew



On Wed, Oct 31, 2012 at 4:03 AM, Guy Thomas wrote:

> I finished my first (basic) set-up of a CAS server and two CAS clients. In
> order to organize the information I found on the CAS site, in the mailing
> list and on the internet I created a document (MS-Word and PDF). It also
> contains some questions left after the initial set-up.
>
> ** **
>
> I don’t know if people in this list struggling with a first set-up might
> be interested. If that’s the case, I’ll gladly share the information with
> you as is. Of course, you have to be aware that the document can and
> certainly will contain incorrent statements, assumptions, etc. Maybe an
> experienced CAS administrator could go through the document and correct the
> most obvious flaws.
>
> ** **
>
> If people are interested, what’s the best way to distribute the
> information in the document?
>
> ** **
>
> The set-up has two special “features”:
>
> **·  **A user who wants to log in has to provide a “domain” next to a
> username and a password. A domain is a protected environment on the web,
> for example an extranet.
>
> **·  **Authenticating a user is realized by means of a (SOAP-based)
> web service. A client layer for this web service is integrated in the CAS
> server. This can be considered an indirect variant of JDBC authentication.
> 
>
> ** **
>
> ** **
>
> ** **
>
> Guy Thomas
>
> Analist-Programmeur
>
> Dienst Projecten en Ontwikkelingen
>
> ** **
>
> Provinciehuis
>
> Provincieplein 1
>
> 3010 Leuven
>
> ** **
>
> Tel: 016267945
>
> ** **
>
>
> --
> Aan dit bericht kunnen geen rechten worden ontleend. Alle berichten naar
> dit professioneel e-mailadres kunnen door de werkgever gelezen worden. In
> het kader van de vervulling van onze taak van openbaar belang nemen wij uw
> relevante persoonlijke gegevens op in onze bestanden. U kunt deze inzien en
> verbeteren conform de Wet Verwerking Persoonsgegevens van 8 december 1992.
>
> Het ondernemingsnummer van het provinciebestuur is 0253.973.219
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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] ajax call on login page

[Andrew Petro]

Hi Guy,

Yes, at the least, you'll need to declare the path in web.xml that you'd
like the servlet container to hand off to some servlet.

In the default web.xml :

https://github.com/Jasig/cas/blob/v3.5.1/cas-server-webapp/src/main/webapp/WEB-INF/web.xml

specific paths like /login and /serviceValidate are mapped to the "cas"
servlet, which is in turn realized using Spring WebMVC.

e.g. :



cas

/login
  




You'd need an entry like that for /domsecservice to map that
url-pattern to some servlet, whether that's the cas servlet (because
you're then implementing your custom functionality inside the
cas-servlet Spring WebMVC configuration) or some other servlet.

Best wishes,

Andrew




On Tue, Nov 13, 2012 at 5:06 AM, Guy Thomas wrote:

> I added a “domain” field to the CAS login page. For testing I used an
> input text field in which the user had to specify a hardcoded value.
>
> Now I want to replace the text field with a selection list (of domains)
> which is put together when the user has entered his username and
>
> leaves the username field (jquery onBlur). In the onBlur callback I want
> to make a Ajax call to a servlet/controller/..
>
> ** **
>
> I tried with a servlet registered in web.xml which I first tried to run
> directly in the address bar:
>
>
> https://(machinename):11143/cas/domsecservice/userdomains?username=(username)&role=ROLE_DOMAIN_USER
> 
>
> ** **
>
> However, this is always redirected to
> https://(machinename):11143/cas/login?...
>
> ** **
>
> I really don’t know how to handle this. Do I have to create a mvc
> controller? Do I have to add this to cas-servlet.xml or to web.xml? Or …?*
> ***
>
> ** **
>
> This is the controller I created but I do not how to access it in the Ajax
> call or how to configure it.
>
> ** **
>
> --
>
> ** **
>
> *package* be.vlaamsbrabant.cas.extension.controllers;
>
> ** **
>
> *import* java.io.IOException;
>
> *import* java.util.HashMap;
>
> *import* java.util.Map;
>
> ** **
>
> *import* org.apache.log4j.Logger;
>
> *import* org.codehaus.jackson.JsonGenerationException;
>
> *import* org.codehaus.jackson.map.JsonMappingException;
>
> *import* org.codehaus.jackson.map.ObjectMapper;
>
> *import* org.springframework.stereotype.Controller;
>
> *import* org.springframework.web.bind.annotation.RequestMapping;
>
> *import* org.springframework.web.bind.annotation.RequestMethod;
>
> *import* org.springframework.web.bind.annotation.RequestParam;
>
> *import* org.springframework.web.bind.annotation.ResponseBody;
>
> ** **
>
> *import* be.vlaamsbrabant.domainsecurity.DomainSecurityClient;
>
> *import* be.vlaamsbrabant.domainsecurity.DomainSecurityClientFactory;
>
> *import* be.vlaamsbrabant.domainsecurity.wsdl.DomainSecurityException;
>
> ** **
>
> @Controller
>
> @RequestMapping(value = "/domsecservice")
>
> *public* *class* DomainSecurityServiceController
>
> {
>
>//
> --
> 
>
>*private* *static* Logger *logger*   = Logger.*getLogger*
> (DomainSecurityServiceController.*class*);
>
> ** **
>
>//
> --
> 
>
>/**
>
> * *@param* username
>
> * *@param* role
>
> * *@return*
>
> */
>
>@RequestMapping(value = "/userdomains", method = RequestMethod.*GET*)**
> **
>
>*public* @ResponseBody
>
>String getDomainUsers(@RequestParam String username, @RequestParamString 
> role)
> 
>
>{
>
>   *logger*.debug("DomainSecurityServiceRequestor::getDomainUsers");***
> *
>
> ** **
>
>   // if more than one role, they must be separated with a semicolon***
> *
>
>   String[] roles = role.split(";");
>
> ** **
>
>   // get domains for given username and role from domain security web
> service
>
>   // via client library
>
>   DomainSecurityClient dsClient = DomainSecurityClientFactory.*
> getInstance*();
>
>   Map userDomains = *new* HashMap();**
> **
>
>   *try*
>
>   {
>
>  *for* (String r : roles)
>
>  {
>
> Map retDomains =
> dsClient.getUserDomains(username, r);
>
> *for* (String dName : retDomains.keySet())
>
> {
>
>*if* (!userDomains.containsKey(dName))
> userDomains.put(dName, retDomains.get(dName));
>
> }
>
>  }
>
>   }
>
>   *catch* (DomainSecurityException dse)
>
>   {
>
>  *logger*.error(dse);
>
>   }
>
> ** **
>
>   // insert userDomains map in other map so that we have a "header"
> field in the generated Json
>
>   Map> userDomainsWrapper = 
> *new*HashMap>();
> 
>
>   userDomainsWrapper.put("domains", userDomains);
>
> ** **
>
>   // build json representation o

Re: [cas-user] Cas Rest Logout

[Andrew Petro]

NIcola,

Strange.

Are you sure this configuration is updated in the
argumentExtractorsConfiguration.xml in the CAS web application as deployed
to your servlet container, and that you've restarted the servlet container
since making this configuration change?

Andrew




On Thu, Nov 15, 2012 at 8:34 AM, Nicola Zannino  wrote:

> Hi, tanks for answer, I already tried this way:
>
>
>  class="org.jasig.cas.web.support.CasArgumentExtractor"
>  p:httpClient-ref="httpClient"
>  p:disableSingleSignOut="true" />
>
>class="org.jasig.cas.web.support.SamlArgumentExtractor"
>  p:httpClient-ref="httpClient"
>  p:disableSingleSignOut="true" />
>
> but doesnt work, cas sends logout anyway.
> Nicola.
>
> 2012/11/15 jleleu 
>
>>  Hi,
>>
>> It's defined in the argumentExtractorsConfiguration.xml file :
>> > class="org.jasig.cas.web.support.CasArgumentExtractor"
>>  p:httpClient-ref="noRedirectHttpClient"
>>  p:disableSingleSignOut="${slo.callbacks.disabled:false}" />
>>
>> Just set the slo.callbacks.disabled property to true in your
>> cas.properties file to disable logout.
>> Best regards,
>> Jérôme
>>
>> --
>> You are currently subscribed to cas-user@lists.jasig.org as:
>> n.zann...@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: ape...@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] Domino iNotes client - how to create and return LTPA Cookie

[Andrew Petro]

Hi Gil,

While Unicon's first pass at bridging to LTPA also involved modifying the
CAS server to add this feature, review and refactor led to an architecture
of a separate bridge application instead.

I'm a big fan of this architecture, incidentally.  Keep CAS simple and
focused on doing what it does well -- the CAS protocol - and rely upon
authenticating to bridge applications to translate to other protocols.  In
this architecture, the Shibboleth IdP, CASified, becomes a really great
bridge for speaking excruciatingly rigorous SAML.

Anyway.  An LTPA bridge, CASified, becomes a much smaller and less
ambitious bridge for speaking passable LTPA.  And here it is:

https://github.com/Unicon/ltpa-bridge

The idea is that it's a simple little Java webapp.  It's a CASified
application.  Your users log into it using CAS, just like any other
CAS-using service.  The bridge computes the LTPA token and redirects the
browser over to the target application with the token.  Install and
configure one of these bridges for each LTPA-consuming application you want
to CAS-integrate.

If that becomes unwieldy, do something fancier and ideally proffer a pull
request. :)

I should mention that this bridge application probably isn't yet in
production anywhere.  It's the refactored and in my view better architected
version of something Unicon initially did as local CAS customizations for a
client.  The customizations it was refactored from have been successfully
in production for months.

Hope to hear about your successful experiences with it.

Kind regards,

Andrew




On Fri, Nov 16, 2012 at 6:30 AM, Gil Victor Teixeira Pinto <
gilc...@gmail.com> wrote:

> I'm trying to integrate iNotes following the tutorial:
>
> https://github.com/apetro/casify-lotus-domino-inotes/wiki/CasifyDominoLotusiNotes
>
> I'm having trouble completing the modifications on the CAS server to
> generate the LTPA token to be returned to the client (Domino / iNotes web
> mail).
> At the forum domino experts<
> http://www.dominoexperts.com/articles/Creating-a-session-for-a-user>
> there are some tips for creating the cookie<
> http://offbytwo.com/2007/0/21/working-with-ltpa.html>,
> but I do not know if the code is correct because I have no idea how to
> return it to the client that is requesting authentication.
>
> I wonder if anyone has some sample code that does this generation of LTPA
> cookie.
>
> Thanks in advance!
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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 Unavailable after renewing LDAP server's SSL cert

[Andrew Petro]

Sean,

This is probably going to turn out to be a certificate trust issue.

So.  You're sure that you exported the right certificate, and imported it
successfully into the right keystore, and that that's the keystore that's
being used by the JVM that your CAS server is running?

Andrew

-- 
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] Domino iNotes client - how to create and return LTPA Cookie

[Andrew Petro]

Gil,

Unfortunately, all the bridge app can do is tee up an LTPA token for Domino
and then flip the user over to Domino, and Domino either accepts or not.
 The bridge application log looks fine as far as they go.  Any chance the
Domino application has logs about its experience of the token in rejecting
it?

Kind regards,

Andrew



On Mon, Nov 19, 2012 at 7:12 AM, Gil Victor  wrote:

> Hi Andrew,
>
> First of all, thank you so much for your response.
> I took some time to learn about new technologies involved in
> "ltpa-bridge", like (gradlew, shiro...).
> As you said, it's better architected make a "bridge" app to communicate
> whit CAS, instead of a implementation directly inside CAS.
>
> I did some configuration to fit my environment (files attached):
> - ltpa.properties
> - shiro.ini
>
> When I try go to "http://localhost:8080/ltpa/token";, it redirects to the
> CAS's login page correctly.
> I enter the user/pass, and after I get the login screen of the iNotes
> e-mail.
>
> Maybe is there some mistake in my configuration's files.
> I attached the log of ltpa-bridge app.
>
> Thanks in advance,
> Gil Victor
>
>
> 2012/11/16 Andrew Petro 
>
>>  Hi Gil,
>>
>> While Unicon's first pass at bridging to LTPA also involved modifying the
>> CAS server to add this feature, review and refactor led to an architecture
>> of a separate bridge application instead.
>>
>> I'm a big fan of this architecture, incidentally.  Keep CAS simple and
>> focused on doing what it does well -- the CAS protocol - and rely upon
>> authenticating to bridge applications to translate to other protocols.  In
>> this architecture, the Shibboleth IdP, CASified, becomes a really great
>> bridge for speaking excruciatingly rigorous SAML.
>>
>> Anyway.  An LTPA bridge, CASified, becomes a much smaller and less
>> ambitious bridge for speaking passable LTPA.  And here it is:
>>
>> https://github.com/Unicon/ltpa-bridge
>>
>> The idea is that it's a simple little Java webapp.  It's a CASified
>> application.  Your users log into it using CAS, just like any other
>> CAS-using service.  The bridge computes the LTPA token and redirects the
>> browser over to the target application with the token.  Install and
>> configure one of these bridges for each LTPA-consuming application you want
>> to CAS-integrate.
>>
>> If that becomes unwieldy, do something fancier and ideally proffer a pull
>> request. :)
>>
>> I should mention that this bridge application probably isn't yet in
>> production anywhere.  It's the refactored and in my view better architected
>> version of something Unicon initially did as local CAS customizations for a
>> client.  The customizations it was refactored from have been successfully
>> in production for months.
>>
>> Hope to hear about your successful experiences with it.
>>
>> Kind regards,
>>
>> Andrew
>>
>>
>>
>>
>>  On Fri, Nov 16, 2012 at 6:30 AM, Gil Victor Teixeira Pinto <
>> gilc...@gmail.com> wrote:
>>
>>>  I'm trying to integrate iNotes following the tutorial:
>>>
>>> https://github.com/apetro/casify-lotus-domino-inotes/wiki/CasifyDominoLotusiNotes
>>>
>>> I'm having trouble completing the modifications on the CAS server to
>>> generate the LTPA token to be returned to the client (Domino / iNotes web
>>> mail).
>>> At the forum domino experts<
>>> http://www.dominoexperts.com/articles/Creating-a-session-for-a-user>
>>> there are some tips for creating the cookie<
>>> http://offbytwo.com/2007/0/21/working-with-ltpa.html<http://offbytwo.com/2007/08/21/working-with-ltpa.html>>,
>>> but I do not know if the code is correct because I have no idea how to
>>> return it to the client that is requesting authentication.
>>>
>>> I wonder if anyone has some sample code that does this generation of
>>> LTPA cookie.
>>>
>>> Thanks in advance!
>>>
>>> --
>>> You are currently subscribed to cas-user@lists.jasig.org as: 
>>> ape...@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: 
>> gilc...@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: ape...@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] Proxy Ticket expiration while session still active

[Andrew Petro]

The periodic keepalive call to CAS to exercise the PGT sounds like a pretty
good solution to me.

Your CAS server is configured so that PGTs have an idle timeout.  Maybe
that timeout is too short, or maybe you'd rather they had only a hard
timeout.  Or maybe you'd rather they had no timeout at all and expired only
when the end user's CAS single sign-on session ends.

But if your CAS server configuration accurately reflects your desired
policy, that idle PGTs after some amount of time become invalid, then
either expiring the PGT is the right outcome and the knob to turn is to
hone the experience in your CAS-using application (say, logging in again
via CAS is undertaken within the active session rather than creating a new
session, an attractive lightbox experience advising the user that their CAS
proxying session expired and that they need to re-authenticate.

And if you don't desire this particular application's PGTs to expire after
the idle timeout while the application is actively used, but want to retain
that idle timeout in general, then your solution of artificially making the
PGT seem actively used while the end user session persists sounds like a
decent solution to keeping that policy in the CAS server yet getting the
desired behavior in this application.

Andrew




On Wed, Nov 21, 2012 at 10:01 AM,  wrote:

>  Hi,
>
> I'm facing an odd problem.
> A user connects to an app, by using a ST. The app asks for a PGT. Until
> now, no problem. The user do his stuff in the app, sometimes calling
> casified-webservice, thus asking CAS for a PT. Sometimes the user doesn't
> use the webservice during, for example 2 hours (TGT/PGT default expiration
> time), but still use actively the app. When 3 hours later (for example) the
> app asks for a PT for the webservice, the PGT is expired, and the user MUST
> be disconnected to get another valid PGT. It's a bit awkward having to
> disconnect the user while the user have been active during all this time.
>
> Is there any solution ? How to "synchronize" use of the app (the user
> session) and PGT expiration.
>
> For now, we made a quick and dirty thing : a periodic call to CAS for PT,
> without using it, just to keep the PGT alive :-/
>
> Any ideas ?
>
> Thanks
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] Proxy Ticket expiration while session still active

[Andrew Petro]

A ticket that is a child of an invalid TGT is invalid.  CAS climbs the
ticket chain to verify that it's valid all the way up.

In AbstractTicket [1] the isExpired() method will only consider a ticket
un-expired if the granting ticket (if present) is unexpired.

public final boolean isExpired() {
return this.expirationPolicy.isExpired(this) ||
(getGrantingTicket() != null && getGrantingTicket().isExpired()) ||
isExpiredInternal();
}


[1]:
https://github.com/Jasig/cas/blob/v3.5.1/cas-server-core/src/main/java/org/jasig/cas/ticket/AbstractTicket.java

Andrew



On Wed, Nov 21, 2012 at 4:23 PM, Ohsie, David  wrote:

> ** **
>
> Your CAS server is configured so that PGTs have an idle timeout.  Maybe
> that timeout is too short, or maybe you'd rather they had only a hard
> timeout.  Or maybe you'd rather they had no timeout at all and expired only
> when the end user's CAS single sign-on session ends.
>
> ** **
>
> Question: If a PGT has not timed out, but the original TGT used to
> generate that PGT has timed out, will the PGT still be usable?
>
> ** **
>
> But if your CAS server configuration accurately reflects your desired
> policy, that idle PGTs after some amount of time become invalid, then
> either expiring the PGT is the right outcome and the knob to turn is to
> hone the experience in your CAS-using application (say, logging in again
> via CAS is undertaken within the active session rather than creating a new
> session, an attractive lightbox experience advising the user that their CAS
> proxying session expired and that they need to re-authenticate.
>
> ** **
>
> And if you don't desire this particular application's PGTs to expire after
> the idle timeout while the application is actively used, but want to retain
> that idle timeout in general, then your solution of artificially making the
> PGT seem actively used while the end user session persists sounds like a
> decent solution to keeping that policy in the CAS server yet getting the
> desired behavior in this application.
>
> ** **
>
> Andrew
>
> ** **
>
> ** **
>
> ** **
>
> On Wed, Nov 21, 2012 at 10:01 AM,  wrote:
>
>  Hi,
>
> I'm facing an odd problem.
> A user connects to an app, by using a ST. The app asks for a PGT. Until
> now, no problem. The user do his stuff in the app, sometimes calling
> casified-webservice, thus asking CAS for a PT. Sometimes the user doesn't
> use the webservice during, for example 2 hours (TGT/PGT default expiration
> time), but still use actively the app. When 3 hours later (for example) the
> app asks for a PT for the webservice, the PGT is expired, and the user MUST
> be disconnected to get another valid PGT. It's a bit awkward having to
> disconnect the user while the user have been active during all this time.
>
> Is there any solution ? How to "synchronize" use of the app (the user
> session) and PGT expiration.
>
> For now, we made a quick and dirty thing : a periodic call to CAS for PT,
> without using it, just to keep the PGT alive :-/
>
> Any ideas ?
>
> Thanks
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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: 
> david.oh...@emc.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: ape...@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

[cas-user] TGT, ST, and PGT expiration configuration

[Andrew Petro]

David,

Clever with the meta data populator.  I expect there's an easier way, but I
didn't go looking further, and your meta data populator solution sounds
feasible.

A more strategic question: are there use cases for separating PGT
expiration policy from TGT expiration policy?  Might a CAS adopter
reasonably want single sign-on sessions that are longer in duration than
the proxying sessions of applications users log into?  I suspect yes, that
I might well want to put a tighter hard timeout on an application's ability
to proxy on my behalf than on the single sign-on TGT token in my browser.

Indeed, for CAS adopters using PGTs only for ClearPass password replay
integrations, PGTs need be valid for only an eyeblink, and there's some
advantage to expiring them out as soon as possible rather than leaving
active a PGT capable of getting a PT capable of retrieving the end user's
password.

Given that, would it make sense for CAS to out-of-the-box tease this apart,
providing a plugin/configuration point for TGT expiration, for ST
expiration, and for PGT expiration, explicitly; that is, 3, rather than 2,
expiration policy entries in the relevant XML configuration file and in
cas.properties?

I do expect the TGT expiration policy could be coded to differentiate and
apply differential policies to TGTs vs PGTs, but that's sounding like a
complex, custom solution to what might be configuration that could be
expressed more simply by exposing more of the conceptual domain (TGTs, STs,
PGTs) in ticket expiration configuration.

Kind regards,

Andrew



On Wed, Nov 21, 2012 at 6:58 PM, Ohsie, David  wrote:

> An iteresting approach might then be to avoid directly expiring PGT's and
> let them completely rely on parent TGT expiration (I think that is one of
> your possibilities below).  
>
> ** **
>
> Is there a way to actually create a PGT expiration policy that differs
> from the TGT expiration policyt?  Since TicketState doesn't seem to offer
> the information about a ticket being a PGT, I would imagine that you have
> to create a "AuthenticationMetaDataPopulator" similar to the 
> "RememberMeAuthenticationMetaDataPopulator" to
> indicate in the Authentication that this is a PGT and have the expiration
> policy look at that flag.  Or maybe there is an easier way…
>
> ** **
>
> *From:* Andrew Petro [mailto:ape...@unicon.net]
> *Sent:* Wednesday, November 21, 2012 4:44 PM
> *To:* cas-user@lists.jasig.org
> *Subject:* Re: [cas-user] Proxy Ticket expiration while session still
> active
>
> ** **
>
> A ticket that is a child of an invalid TGT is invalid.  CAS climbs the
> ticket chain to verify that it's valid all the way up.
>
> ** **
>
> In AbstractTicket [1] the isExpired() method will only consider a ticket
> un-expired if the granting ticket (if present) is unexpired.
>
> ** **
>
> ** **
>
> ** **
>
> *public* *final* *boolean* *isExpired**()* *{*
>
> ** **
>
> ** **
>
> *return* *this.*expirationPolicy*.*isExpired*(this)* *||* 
> *(*getGrantingTicket*()* *!=* *null* *&&* 
> getGrantingTicket*().*isExpired*())* *||* isExpiredInternal*();*
>
> ** **
>
> ** **
>
> *}*
>
> ** **
>
> [1]:
> https://github.com/Jasig/cas/blob/v3.5.1/cas-server-core/src/main/java/org/jasig/cas/ticket/AbstractTicket.java
> 
>
> ** **
>
> Andrew
>
> ** **
>
> ** **
>
> On Wed, Nov 21, 2012 at 4:23 PM, Ohsie, David  wrote:
> 
>
>  
>
> Your CAS server is configured so that PGTs have an idle timeout.  Maybe
> that timeout is too short, or maybe you'd rather they had only a hard
> timeout.  Or maybe you'd rather they had no timeout at all and expired only
> when the end user's CAS single sign-on session ends.
>
>  
>
> Question: If a PGT has not timed out, but the original TGT used to
> generate that PGT has timed out, will the PGT still be usable?
>
>  
>
> But if your CAS server configuration accurately reflects your desired
> policy, that idle PGTs after some amount of time become invalid, then
> either expiring the PGT is the right outcome and the knob to turn is to
> hone the experience in your CAS-using application (say, logging in again
> via CAS is undertaken within the active session rather than creating a new
> session, an attractive lightbox experience advising the user that their CAS
> proxying session expired and that they need to re-authenticate.
>
>  
>
> And if you don't desire this particular application's PGTs to expire after
> the idle timeout while the application is actively used, but want to retain
> that idle timeout in general, then your solution of ar

[cas-user] Governments using CAS?

[Andrew Petro]

Seeking references for successful use of Jasig CAS in non-education
government contexts.  Municipalities, counties, states, nations -- any
institutions along those lines using CAS?

Would love to help add any of these to

http://www.jasig.org/cas/deployments

.

Kind regards,

Andrew

-- 
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 and Login Intercepts

[Andrew Petro]

Hi Eric,

Welcome to the CAS community. :)

You might find this a good starting point for password change, password
bootstrapping, etc.:

https://github.com/Unicon/cas-password-manager

CAS has features for automatically failing login attempts after too many
failures too quickly.  I posted about that recently here:

http://www.unicon.net/blog/apetro/failed_login_attempt_throttling_cas

You're right that current CAS doesn't differentiate between failure because
of throttling failed login attempts versus failure because the password was
wrong.  Differentiating is probably a good idea allowing a better user
experience, and of course once it was differentiating you could customize
the differentiated error message to suggest the password reset opportunity.


A common current practice is simply to put the account recovery link on the
CAS login form page and users once sufficiently frustrated will click it to
recover their account.

Hope this helps,

Andrew





On Tue, Dec 11, 2012 at 12:38 PM, Stein, Eric  wrote:

> Hi,
>   I'm running CAS 3.5.0. I've got a trivial application authenticating
> to our database (Yay!). I've now been tasked with adding all the
> standard stuff - change password screen, forgot password screen, user
> locked out after N failed attempts, etc. I haven't seen any
> documentation on the jasig site about doing any of these things.
>
> I have two webapps right now:
> hello-world.war - client application
> locus-cas-webapp - a CAS war overlay application
>
> a) Change password/forgot password - do these go in a third webapp, or
> can I put them in locus-cas-webapp?
> b) How do I lock out a user if they fail to log in X times? My current
> setup would have me updating a column in USER_TABLE.
> c) If the user is locked out, I'd like to push them to the "forgot
> password" screen. I didn't see any hooks into this kind of behaviour -
> how would this be handled?
> d) If a user has a temporary password (created by the forgot password
> screen and currently tracked in a column in USER_TABLE), how do I
> redirect them to the "change password" screen?
>
> For (c) and (d) it seems like I need a hook into CAS after the
> authentication information is entered and either before the
> authentication is performed or post-authentication and pre-forwarding.
>
> I've been doing java forever, but I know nothing about Spring, so please
> modulate any answers accordingly.
>
> Thanks very much,
> Eric Stein
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] HTTP status 404

[Andrew Petro]

Hi Guillaume,

> For example* :** …Caused by:
org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean
named 'contextSource' is defined…*
*
*
Okay. The cause of that specifically is that there's no bean named
"contextSource" defined.  :)*
*

So you've got this bean declaring the LDAP authentication handler:



So far so good.  But this bean had a dependency on another bean named
"contextSource.  That's what the p:contextSource-ref="contextSource" is
saying.  It's saying there's a setContextSource() method on the
BindLdapAuthenticationHandler instance and we want Spring to call that
setter, injecting in the bean named "contextSource".  (Spring knows it's a
reference to a bean because of the "-ref" in the property name.).

It's dense but one gets used it it surprisingly fast.

Anyway.  One immediate problem with your deployerConfigContext.xml is that
there *isn't* a bean named "contextSource" for Spring to find and inject.
 Hence the error message you're getting.  You need to define a bean named
"contextSource" that is an LDAP context source.

See "Define a Context Source" in this documentation:
https://wiki.jasig.org/display/CASUM/LDAP .

Hope this helps,

Andrew




On Wed, Dec 12, 2012 at 6:37 AM, Guillaume Dépinay <
guillaume.depi...@bordeaux.archi.fr> wrote:

>  Hello,
>
> Thanks for so quick answers.
>
> ** **
>
> Under the dependency under pom.xml ** **
>
>  ${project.groupId}
> cas-server-support-ldap
> ${project.version} 
>
> Change the following
>
> ${project.version} to 3.4.11 and rebuild your project
>
> ** **
>
> I did dit but nothing change.
>
> ** **
>
> As said by M. Addison, there’s issues to fix when tomcat deploy.
>
> It seems to be wrong bean and context source declarations in
> deployerConfigContext.xml. 
>
> For example* :** …Caused by:
> org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean
> named 'contextSource' is defined…*
>
> I’m pretty young with xml (more than in English ☺ ) so I check further in
> logs, give tries with what I’ll find and I tell you.
>
> ** **
>
> Why 3.4.11 ?
>
> Because when I tried first time it to deploy cas, it was the last stable
> version.
>
> Also, I followed a tutorial with this one so I thought it ‘ll be better to
> keep the same version.
>
> ** **
>
> ** **
>
> Thanks again for help.
>
> Good day
>
> ** **
>
> ** **
>
> De : Farzan Qureshi [mailto:fqure...@rosmini.school.nz] ** **
>
> Envoyé : mardi 11 décembre 2012 19:05
>
> À : cas-user@lists.jasig.org
>
> Objet : Re: [cas-user] HTTP status 404
>
> ** **
>
> Hi,
>
> Under the dependency under pom.xml ** **
>
>  ${project.groupId}
> cas-server-support-ldap
> ${project.version} 
>
> Change the following
>
> ${project.version} to 3.4.11 and rebuild your project with
>
> mvn clean install 
>
> Just wondering why you are not running current version of CAS that is
> 3.5.1.
>
> I configured my CAS few days ago with my ldap. Let us know if you need
> further help.
>
> I followed instructions on following link
>
>
> https://wiki.jasig.org/display/CASU/Best+Practice+-+Setting+Up+CAS+Locally+using+the+Maven2+WAR+Overlay+Method
> 
>
> Farzan Qureshi 
>
> --
>
> Rosmini College
>
> Network Administrator & Helpdesk support 
>
> Sent from my SIII
>
> Hye,
>
> ** **
>
> I'm new to CAS and I try to make it work in our school.
>
> Everything's work fine in demo version.
>
> ** **
>
> So I make changes in deployerConfigContext.xml and pom.xml to authenticate
> with our Active  Directory.
>
> ** **
>
> When I build my project I got the message  BUILD SUCCESS.
>
> Then I copy cas.war in /var/lib/tomcat6/webapps and reload tomcat deamon.*
> ***
>
> ** **
>
> My issue is when I try to reconnect with my browser, I get 404 error :
>
> -
>
> HTTP Status 404 -
>
> type Status report
>
> message description The requested resource () is not available.
>
> -
>
> ** **
>
> So, I put back original files, build again and everything's back to normal
> (demo).
>
> I guess it's something wrong in my conf but I 've been searching 3 days
> for nothing. If someone s' got a clue, I 'll be thankful.
>
> ** **
>
> The modifications I made :
>
> In cas-server-3.4.11/cas-server-webapp/pom.xml I declare ldap dependency :
> 
>
> 
>
> 
>
> ${project.groupId}
>
> cas-server-support-ldap
>
> ${project.version}
>
> 
>
> -
>
> ** **
>
> In
> cas-server-3.4.11/cas-server-webapp/src/main/webapp/WEB-INF/deployerConfigContext
> I add bean adaptatorLdap and ldap context.
>
> ** **
>
> -
>
> 
>
> 
>
>  class="org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler"
> 

Re: [cas-user] Note to ClearPass users of CAS 3.5

[Andrew Petro]

I agree the right improved feature here is for ClearPass to only accept
proxy tickets with blessed non-empty proxy chains, which is to say for
ClearPass to reject service tickets.

I'd like to put a little context behind the current behavior of accepting
service tickets.

In concept, what's going on in CAS is end-user authentication (obtaining a
TGT representing an SSO session, obtaining STs off of that to authenticate
to particular applications) and then the end-user delegating authentication
authority to the applications he logs into (proxy tickets).  I log into
uPortal via CAS and thereby delegate to it authority to authenticate as me
to services that trust my authority delegated through the portal.  And so
uPortal might then be able to authenticate to ClearPass on my behalf.

The conceptual abstraction is that uPortal is able to use a sliver of my
authority to authenticate to a sliver of the stuff I would have been able
to authenticate to.

That was the design.  That's why service tickets are valid wherever any
proxy ticket would have been valid in the Yale Java CAS client and, until
Misagh's patch is realized, in the Jasig Java CAS Client.

It turns out that design concept needs evolved, that there are use cases
where you want an application (itself authenticated via proxy callback)
exercising a user's delegated authority to access services in addition to
rather than just a subset of those you'd have allowed the end user to
access directly.  I.e. ClearPass.  Allow the user to exercise ClearPass
when delegating authority through uPortal or through the OWA bridge but not
allow the user to exercise ClearPass when exercising his authority directly
without delegation.

Okay.  CAS is already fully communicating the proxy chain on PT validation,
so this is just an evolution of the client libraries.  This additional
discrimination of what tickets to accept can already be achieved today in
the Jasig Java CAS Client by adding an additional filter to reject service
tickets that the Client would otherwise have accepted, since the proxy
chain is exposed in the session (or Request) after the Client parses it.

This pull request seems to be working towards making that extra
ServiceTicketRejectingFilter unnecessary, instead adding a configuration
option to the Java CAS Client ticket accepting filter to configure whether
it should accept Service Tickets, that is, tickets with empty proxy chains.


https://github.com/Jasig/java-cas-client/pull/24

Were that option available in the Java CAS Client, the ClearPass usage
would configure it to reject Service Tickets, and that would block
end-users from directly authenticating to the ClearPass service to view
their password.

I suggest that's the right path forward.

Kind regards,

Andrew



On Thu, Dec 13, 2012 at 11:17 PM, Misagh Moayyed wrote:

> I’d like to add a few notes here on forcing clearPass to only be available
> via proxy authentication. 
>
> ** **
>
> I recently discovered that turning off the casAuthenticationFilter alone
> is not sufficient to disable clearPass from directly rendering credentials
> on the page. It is still possible for clearPass to render credentials on
> the page using the following URL:
>
>
> https://sso.server.edu/cas/login?service=https://sso.server.edu/cas/clearPass
> 
>
> ** **
>
> This is seemingly due to the fact that the Java CAS client and
> specifically its proxy-enabled validation filter allows for an empty proxy
> chain that is constructed by the above URL. Until the next CAS client
> release, the quick remedy is to provide an extension of the
> ‘Cas20ProxyTicketValidator’ which would be responsible to disallowing empty
> proxy chains. 
>
> ** **
>
> Regards, 
>
> *-*Misagh*
>
> *
>
> ** **
>
> *From:* Domazlicky, Eric [mailto:edomazli...@tacomacc.edu]
> *Sent:* Wednesday, December 05, 2012 10:04 AM
> *To:* cas-user@lists.jasig.org
> *Subject:* [cas-user] Note to ClearPass users of CAS 3.5
>
> ** **
>
> I would recommend to any users of CAS 3.5 with ClearPass configured to
> take a look at the changes in the pull request for CAS-1209:
>
> https://issues.jasig.org/browse/CAS-1209
>
> https://github.com/Jasig/cas/pull/151
>
> ** **
>
> Basically the pull request removes the CAS Authentication Filter from
> clearPass-configuration.xml. If you don’t remove the CAS Authentication
> filter your user’s cleartext passwords can be disclosed if an attacker
> gains access to their browser session and visits the clearPass URL (usually
> https://server.edu/cas/clearPass). With the CAS Authentication Filter
> disabled in clearPass-configuration.xml, the remaining CAS Proxy Filter
> protects against an attacker seeing the cleartext password, even if they
> gain access to the user’s browser session by use of the allowedProxyChains
> attribute. 
>
> ** **
>
> This may seem like a pretty remote security issue since the attacker has
> to gain access to the users’ browser session first. But at least in a
> Hig

Re: [cas-user] System requirements for latest CAS

[Andrew Petro]

Larry,

(This is a post along the lines of what I sent you directly earlier this
morning, for everyone's benefit. :) )

Congratulations on your upgrade.

The short version is that any halfway-decent recent server you've got is
fine.  Really.  CAS runs on commodity server hardware, no worries.  I like
isolating CAS from other applications on principle, but if you wanted it
would almost certainly run fine alongside anything else you've got on any
server you're already running.

CAS doesn't do much.  Needs some RAM to store the ticker registry.  Needs
some disk to write log files.  You're probably offloading SSL to something
in front of it so it doesn't even have much CPU load.

Kind regards,

Andrew


On Fri, Dec 14, 2012 at 10:39 AM, Peng Zhang  wrote:

>  Hi,
>
> ** **
>
> We are currently upgrading our CAS to the latest version 3.5.1. What is
> the minimal system requirements for it?
>
> ** **
>
> Thank you very much,
>
> Larry
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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] Custom Credentials

[Andrew Petro]

Hi,

You'll need a custom Credentials implementation representing your
credentials, in this case the signed chunk of data.

You'll need a custom CredentialsToPrincipalResolver to determine whom your
Credentials are trying to authenticate (username).

You'll need a custom AuthenticationHandler to accept or reject the
presented Credentials.

You'll need to wire these pieces up in Spring and you'll need to customize
the login UI JSPs and web flow to provide the user experience for
soliciting and accepting your signed data credential, unless we're talking
only applications logging in in this way, in which case there's no UI as
such.

Hope this helps,

Andrew



On Thu, Jan 3, 2013 at 9:05 AM, kanzel  wrote:

> Can anybody tell me what are the steps to create custom credentials?
> I want to login only by signing some data with certificate and authenticate
> in that way.
> Thanks in advance... :)
>
>
>
> --
> View this message in context:
> http://jasig.275507.n4.nabble.com/Custom-Credentials-tp4657409.html
> Sent from the CAS Users mailing list archive at Nabble.com.
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] Any way to relay language selection back to the application?

[Andrew Petro]

Peter,

Interesting idea.

No, there's no support in CAS currently for conveying the user's language
selection back to the relying application.

If you wanted to customize to do that, you might model the language
selection as a user attribute.

Kind regards,

Andrew



On Thu, Jan 3, 2013 at 1:49 PM, Peter Z  wrote:

> Any way for app to retrieve language selection made by user in SSO login
> screen?
>
> thanks!
> Peter
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] Apereo (Jasig/Sakai) Unconference Topics of Interest

[Andrew Petro]

Bill,

Thanks for that page.  I see topics there I'd especially like to discuss
and work on at the UnConference, including 2fa for CAS, CAS4 protocol,
attributes in CAS, LOA in CAS, and CIFER enterprise web SSO entailing ever
more love and integration between CAS and Shib.

A related question: who is attending the UnConference?  I created a page
for listing participants from the stub link that had been in the wiki:

https://wiki.jasig.org/display/JCON/2013+Unconference+List+of+Participants

As is traditional, there's space for noting interests and expertise.

I've seeded it with Unicon's ambitions for sending many Uniconers since
this event is close to the Gilbert office; I'd love to see the page filled
out with other participants as well to help fuel thinking about making
connections and collaborating as the UnConference approaches.

Kind regards,

Andrew





On Wed, Jan 2, 2013 at 4:39 PM, William G. Thompson, Jr.
wrote:

> Folks,
>
> A list of potential topics of interest for the Apereo (Jasig/Sakai)
> Unconference  has been started in the Jasig Wiki:
> https://wiki.jasig.org/display/JCON/2013+Unconference+Topics+of+Interest
>
> Even if you not planning on attending feel free to add your thoughts.
>
> Best,
> Bill
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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 and IDP solution

[Andrew Petro]

Hi Farzan,

If you want to do SAML integrations complete with IdP metadata and so
forth, I recommend bridging to the Shibboleth IdP to handle SAML heavy
lifting.

Shibboleth IdP is CASifiable such that users log in via CAS.  End user
experience is still CAS login.  Vendor / integrator experience is
full-featured SAML2 with metadata and federation support and all the
excruciatingly rigorous standards you can stand. :)  The combination has
worked out pretty well at numerous adopters.

Kind regards,

Andrew



On Tue, Jan 8, 2013 at 4:18 PM, Farzan Qureshi
wrote:

> Hi,
>
> We are running an application. The vendor of the application is asking us
> to send an idp metadata file so that they can generate saml response and
> enable SSO functionality in the app. May I know how I should go about this?
> We have casified several applications but haven't gone through this step
> thus not sure what they are asking for or how do I provide the requested
> metadata file. Does anyone of you have ideas?
>
> Kind regards,
>
> Farzan
>
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system manager (
> ad...@rosmini.school.nz). Please note that any views or opinions
> presented in this email are solely those of the author and do not
> necessarily represent those of the company. Finally, the recipient should
> check this email and any attachments for the presence of viruses. Rosmini
> College accepts no liability for any damage caused by any virus
> transmitted by this email.
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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 and IDP solution

[Andrew Petro]

Hi Farzan,

Shibboleth can be complex, yes, with much to learn about it and many
opportunities to configure.

The CAS-Shibboleth bridging piece isn't too bad.  Here's my favorite
solution:

https://github.com/Unicon/shib-cas-authenticator

I thought this presentation was pretty good:

https://wiki.jasig.org/x/AxMoAw

Hope that helps,

Andrew




On Wed, Jan 9, 2013 at 2:13 PM, Farzan Qureshi
wrote:

> Hi Andrew,
>
> Do you know any source of good documentation on bridging CAS and
> Shiboleth? Shibboleth is very complex to configurebut as it is now a
> requirement at my organization thus i am studying how it works.
>
> Please guide me how to start. We have a working cas install and several
> applications are casified and running successfully.
>
> Thanks for your help.
>
> Farzan
>
>
> On Thursday, 10 January 2013, Andrew Petro  wrote:
> > Hi Farzan,
> > If you want to do SAML integrations complete with IdP metadata and so
> forth, I recommend bridging to the Shibboleth IdP to handle SAML heavy
> lifting.
> > Shibboleth IdP is CASifiable such that users log in via CAS.  End user
> experience is still CAS login.  Vendor / integrator experience is
> full-featured SAML2 with metadata and federation support and all the
> excruciatingly rigorous standards you can stand. :)  The combination has
> worked out pretty well at numerous adopters.
> > Kind regards,
> > Andrew
> >
> >
> > On Tue, Jan 8, 2013 at 4:18 PM, Farzan Qureshi <
> fqure...@rosmini.school.nz> wrote:
> >>
> >> Hi,
> >>
> >> We are running an application. The vendor of the application is asking
> us to send an idp metadata file so that they can generate saml response and
> enable SSO functionality in the app. May I know how I should go about this?
> We have casified several applications but haven't gone through this step
> thus not sure what they are asking for or how do I provide the requested
> metadata file. Does anyone of you have ideas?
> >>
> >> Kind regards,
> >>
> >> Farzan
> >>
> >> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they are
> addressed. If you have received this email in error please notify the
> system manager (ad...@rosmini.school.nz). Please note that any views or
> opinions presented in this email are solely those of the author and do not
> necessarily represent those of the company. Finally, the recipient should
> check this email and any attachments for the presence of viruses. Rosmini
> College accepts no liability for any damage caused by any virus transmitted
> by this email.
> >>
> >> --
> >> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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:
> fqure...@rosmini.school.nz
>
> > To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
> --
> *Farzan Qureshi* | Network Administrator & Help-desk Support | Rosmini
> College | (09) 487 0 530
>
>
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system manager (
> ad...@rosmini.school.nz). Please note that any views or opinions
> presented in this email are solely those of the author and do not
> necessarily represent those of the company. Finally, the recipient should
> check this email and any attachments for the presence of viruses. Rosmini
> College accepts no liability for any damage caused by any virus
> transmitted by this email.
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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] Logging not working as expected

[Andrew Petro]

Schawn,

Could the included-with-CAS CredentialsToPrincipalResolver implementations
include more logging that would better meet your and other adopters needs
for more detailed logging?  Maybe additional log statements at lower
logging priority levels so other CAS adopters can easily avoid the noise?

Kind regards,

Andrew




On Tue, Jan 8, 2013 at 11:44 AM, Schawn E. Thropp wrote:

> I created a custom CredentialsToPrincipalResolver and add support for
> logging:
>
> Support includes:
> - logger attribute: protected final Log logger =
> LogFactory.getLog(this.getClass())
> - added logging statements throughout code (e.g., logger.info("Creating
> principal for...")
>
> However when I go to run the new code the log statements are not
> appearing. I changed the log4j.xml properties to all DEBUG just in case and
> they still are not displaying.  Am I missing something?
>
> Schawn-
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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] Using CAS Proxy to provide "untrusted" apps access to business data services?

[Andrew Petro]

Clever.

Let me summarize as an Untrusted Application is to use a CAS Proxy Ticket
to authenticate to an Institutional Web Service, and you'd like the end
user to be anonymous to the Untrusted Application but known (further,
authenticated) to the Institutional Web Service.

In a normal CAS interaction, the end user would log into the Untrusted
Application using CAS and the Untrusted Application would obtain a Proxy
Granting Ticket in the course of validating the Service Ticket, and would
see the end user's identity from that Service Ticket validation.

Of course, you could configure CAS via the service registry such that the
Untrusted Application *doesn't* get the end user's userid and instead gets
an opaque identifier.  That should solve the
user-is-anonymous-to-the-untrusted-application problem.

The Untrusted Application is going to use that Proxy Granting Ticket to
obtain a Proxy Ticket, and then will present that Proxy Ticket to the
Institutional Web Service to obtain some interesting if anonymized
information.  As you say, the Institutional Web Service is going to need to
redeem that Proxy Ticket for a validation response including the end user's
identity.

And here's a problem.  In normal, ootb CAS, nothing authenticates the
service validating a service or proxy ticket.  So the Untrusted Application
could, instead of presenting the Proxy Ticket to the Institutional Web
Service, instead itself validate the Proxy Ticket with CAS and get the CAS
validation response that was intended for the Institutional Web Service.
 That validation response will have the end user's identity in it.  The end
user is no longer anonymous.

I suppose you could solve that by introducing authentication of the
application requesting ticket validation.  That wouldn't be that hard to
do, whether by shared secret, or SSL client cert.  And then CAS would know
to only validate the proxy tickets intended for the Institutional Web
Service when the Institutional Web Service authenticates for that
validation call.

More generally, yes, CAS and proxy CAS does enable a different kind of
trust of the developers involved.  I worked on Yale's portal as a student
employee.  One neat consequence of proxy CAS is that I *couldn't*
arbitrarily query production web services accepting proxy tickets even
though I was developing portlets (well, then, channels) that exercised
those services. Could only get a valid production proxy ticket in the
context of a real production CAS SSO session, after all.  Very nice, that.

Hope this note helps.  Sounds like a fun project and I hope to hear how it
goes.

Kind regards,

Andrew




On Thu, Jan 10, 2013 at 5:39 PM,  wrote:

> Hi folks,
>
> We have a number of eager and talented student developers who would love
> to be able to build powerful apps to help their peers.  The challenge is
> that many of the richest applications would use sensitive data (e.g. a
> student's Previous/Current Class Enrollments so they could build a Class
> Scheduling App using available Class Schedule data).
>
> It would be inadvisable to allow unknown apps to query sensitive business
> services directly, but it is possible to use CAS Proxy to have the user
> authenticate to a campus page and then redirect the user's browser (along
> with a proxy ticket) to an untrusted app which could then send the proxy
> ticket to a service facade that was set to receive the proxy ticket, get
> the user's ID from CAS using the proxyticket and send the id to a business
> service (e.g. a Transcript Service) and then return the business data (e.g.
> past class enrollments) without any personally identifiable information.
>
> Given this configuration, a student app could take any CAS authenticated
> user and get business data for that user (and only that user) that would be
> appropriate for this purpose (e.g. just business data that has no PII).
> The key is that the untrusted app never receives anything that can be tied
> to the user - all it ever receives is a proxyticket and unidentifiable
> business data.
>
> Has anyone done this already or see any red flags about it?
>
>
> Thanks!
>
> Tom O'Brien
>
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] Using CAS Proxy to provide "untrusted" apps access to business data services?

[Andrew Petro]

proxy ticket from specific
trusted institutional proxying applications. UntrustedApplication would not
be permitted to proxy CAS authenticate directly to
UsernameReleasingWebService.  InstitutionalWebService would.

This solves the problem because applications *are* authenticated when the
obtain proxy granting tickets.  So you can be sure, when you're presented
with a valid proxy ticket, that it came through the described chain.
 Releasing the attribute only in the face of a PT authenticating the
application you want to release the attribute to solves the problem of
authenticating the application obtaining the attribute.

Hope all this helps,

Andrew

[1] : where UntrustedApplication, UntrustedApplicationCallbackUrl,
InstitutionalWebService are all properly encoded URLs :)




On Fri, Jan 11, 2013 at 12:28 AM,  wrote:

> Hi Andrew,
>
> Thanks for the thoughtful response - I hadn't thought to try attempting to
> get the id from the proxyticket in the untrusted app since I was pretty
> sure the proxy request's targetService URL restricted it but that was just
> an assumption!
>
> We've got our CAS locked down so that only approved apps can access it AND
> it also uses the targetService parameter so that only an app at the
> targetService URL can submit the proxyTicket - if the untrusted app (or any
> other) tries to submit it then it gets an error like
>
> ticket 'ST-263-PjTUuKYMKkG7xFsefRgy-cas-t1' does not match supplied
> service. The original service was '.../CASProxyFacade/CASProxy.asp' and the
> supplied service was '.../CASProxyFacade/untrustedapp.asp'.
>
> We'll have to make sure any changes to our config doesn't undo the 
> targetService
> validation!
>
> Any other thoughts or comments - this was very helpful!
>
> Thanks,
>
> Tomo
>
>
>
> On Thu, 10 Jan 2013 18:06:07 -0500, Andrew Petro 
> wrote:
>
> Clever.
> Let me summarize as an Untrusted Application is to use a CAS Proxy Ticket
> to authenticate to an Institutional Web Service, and you'd like the end
> user to be anonymous to the Untrusted Application but known (further,
> authenticated) to the Institutional Web Service.
>  In a normal CAS interaction, the end user would log into the Untrusted
> Application using CAS and the Untrusted Application would obtain a Proxy
> Granting Ticket in the course of validating the Service Ticket, and would
> see the end user's identity from that Service Ticket validation.
>  Of course, you could configure CAS via the service registry such that
> the Untrusted Application *doesn't* get the end user's userid and instead
> gets an opaque identifier.  That should solve the
> user-is-anonymous-to-the-untrusted-application problem.
>  The Untrusted Application is going to use that Proxy Granting Ticket to
> obtain a Proxy Ticket, and then will present that Proxy Ticket to the
> Institutional Web Service to obtain some interesting if anonymized
> information.  As you say, the Institutional Web Service is going to need to
> redeem that Proxy Ticket for a validation response including the end user's
> identity.
>  And here's a problem.  In normal, ootb CAS, nothing authenticates the
> service validating a service or proxy ticket.  So the Untrusted Application
> could, instead of presenting the Proxy Ticket to the Institutional Web
> Service, instead itself validate the Proxy Ticket with CAS and get the CAS
> validation response that was intended for the Institutional Web Service.
>  That validation response will have the end user's identity in it.  The end
> user is no longer anonymous.
>  I suppose you could solve that by introducing authentication of the
> application requesting ticket validation.  That wouldn't be that hard to
> do, whether by shared secret, or SSL client cert.  And then CAS would know
> to only validate the proxy tickets intended for the Institutional Web
> Service when the Institutional Web Service authenticates for that
> validation call.
>  More generally, yes, CAS and proxy CAS does enable a different kind of
> trust of the developers involved.  I worked on Yale's portal as a student
> employee.  One neat consequence of proxy CAS is that I *couldn't*
> arbitrarily query production web services accepting proxy tickets even
> though I was developing portlets (well, then, channels) that exercised
> those services. Could only get a valid production proxy ticket in the
> context of a real production CAS SSO session, after all.  Very nice, that.
>  Hope this note helps.  Sounds like a fun project and I hope to hear how
> it goes.
>  Kind regards,
>  Andrew
>
>
> On Thu, Jan 10, 2013 at 5:39 PM,  wrote:
>
>> Hi folks,
>>
>> We have a number of 

Re: [cas-user] Using CAS Proxy to provide "untrusted" apps access to business data services?

[Andrew Petro]

Tomo,

Clever on the Untrusted Application never uses CAS itself.

The campus page sets the targetService so the Untrusted app can't provide
> an alternate service address.  All the untrusted app ever gets is a
> proxyticket that it passes through to a campus-defined service facade that
> submits the proxyticket to get the user's ID and then use that to call the
> real service.  The untrusted app only ever gets ProxyTickets through
> requests to a campus landing page that is invisible to the user but which
> does the calls to CAS to get the ProxyTicket to give to the Untrusted app.


Okay.  But the Untrusted Application, instead of presenting the proxy
ticket to the Institutional Web Service, can instead validate the proxy
ticket itself with CAS, specifying the service parameter as that of the
Institutional Web Service.  Now the Untrusted Application has the
end-user's username.  And then it drops a cookie or notes the IP address or
even uses fancy browser fingerprinting to "remember" this user.

And then it displays an error page "Sorry, an error occurred.  Please try
again."

And then the end user tries again.  Sames steps to get another Proxy Ticket
to the Untrusted Application.  This time the Untrusted Application presents
that Proxy Ticket to the Institutional Web Service.

And now the Untrusted Application combines the user identity and the
Institutional Web Service's data to break the anonymity.

The problem is that proxy tickets are fundamentally bearer tokens, and if
they pass through the Untrusted Application, the Untrusted Application gets
to be the bearer and can choose to itself redeem the ticket rather than
presenting it to its intended recipient.  You can achieve the anonymity in
the Untrusted Application that you seek by authenticating the Institutional
Web Service when the Institutional Web Service gets the username.  That
could either be by enhancing CAS to support client authentication on the
validation request (i.e., proxy tickets stop being bearer tokens and start
being redeemable only by their intended recipient) or by requiring the
Institutional Web Service to itself get a PGT and use a PT with itself as
the last authenticated proxy in the chain to get the username (proxy
tickets remain bearer tokens, but the Untrusted Application never gets to
bear a token that can be redeemed for a username).

Kind regards,

Andrew




On Fri, Jan 11, 2013 at 12:05 PM,  wrote:

> Andrew,
>
> Thanks for the feedback!
>
> My idea was that the untrusted app has NO direct contact with CAS - it
> redirects to a campus page that redirects to cas (along with a parameter
> that specifies the untrusted app's URL so the campus page can redirect the
> user back to the untrusted app after the authentication with CAS).  CAS
> sends them back to the campus page which then sends the proxyticket as an
> argument in a redirect back to the untrusted app.
>
> Untrusted App - > UCB Landing Page (which gets Untrusted App referrer URL)
> -> CAS (with referrer URL as parameter) -> UCB Landing Page (with referrer
> URL as parameter)  -- CAS call to get ProxyTicket -> Untrusted App (with
> ProxyTicket as parameter)
>
> To the user it looks like they're authenticating from the untrusted app
> but they're really authenticating to a campus page that it is doing all the
> heavy lifting and passing the proxyticket to the untrusted app so it can
> make its service call.  The campus page sets the targetService so the
> Untrusted app can't provide an alternate service address.  All the
> untrusted app ever gets is a proxyticket that it passes through to a
> campus-defined service facade that submits the proxyticket to get the
> user's ID and then use that to call the real service.  The untrusted app
> only ever gets ProxyTickets through requests to a campus landing page that
> is invisible to the user but which does the calls to CAS to get the
> ProxyTicket to give to the Untrusted app.
>
> Does that make more sense?
> Thanks!
>  Tomo
>
>
>
> On Fri, 11 Jan 2013 08:36:58 -0500, Andrew Petro 
> wrote:
>
> Tom,
> > We've got our CAS locked down so that only approved apps can access it
> AND it also uses the targetService parameter so that only an app at the
> targetService URL can submit the proxyTicket - if the untrusted app (or any
> other) tries to submit it then it gets an error
>
> Service identifier checking on ticket validation may not be buying you
> what you think it's buying you. :)
>
> The purpose of service identifier checking on ticket validation, that is,
> the reason that CAS requires that the service= parameter match on
> /cas/login?service= and /cas/serviceValidate?service=, e.g., and on
> /cas/proxy?targetService= and on /cas/proxyValidate?service= , is *not* t

Re: [cas-user] Using CAS Proxy to provide "untrusted" apps access to business data services?

[Andrew Petro]

Eric,

That solves it.  Nicely done.  That amounts to the Untrusted Application no
longer being a bearer of the bearer token (proxy ticket) since if the
encryption works the Untrusted Application never gets to see the plaintext
proxy ticket.

This is a nice solution in that it requires no modification to the CAS
server itself.

Andrew




On Fri, Jan 11, 2013 at 1:15 PM, Domazlicky, Eric
wrote:

>  Andrew,
>
> ** **
>
> Maybe I’m missing something but couldn’t the CAS Proxy Tomo describes
> simply encrypt the Proxy Ticket when presenting it to the untrusted
> application, thus negating the issues with the Untrusted application having
> access to a cleartext Proxy Ticket?****
>
> ** **
>
> *From:* Andrew Petro [mailto:ape...@unicon.net]
> *Sent:* Friday, January 11, 2013 9:34 AM
> *To:* cas-user@lists.jasig.org
> *Subject:* Re: [cas-user] Using CAS Proxy to provide "untrusted" apps
> access to business data services?
>
> ** **
>
> Tomo,
>
> ** **
>
> Clever on the Untrusted Application never uses CAS itself.
>
> ** **
>
> The campus page sets the targetService so the Untrusted app can't provide
> an alternate service address.  All the untrusted app ever gets is a
> proxyticket that it passes through to a campus-defined service facade that
> submits the proxyticket to get the user's ID and then use that to call the
> real service.  The untrusted app only ever gets ProxyTickets through
> requests to a campus landing page that is invisible to the user but which
> does the calls to CAS to get the ProxyTicket to give to the Untrusted app.
> 
>
>  ** **
>
> Okay.  But the Untrusted Application, instead of presenting the proxy
> ticket to the Institutional Web Service, can instead validate the proxy
> ticket itself with CAS, specifying the service parameter as that of the
> Institutional Web Service.  Now the Untrusted Application has the
> end-user's username.  And then it drops a cookie or notes the IP address or
> even uses fancy browser fingerprinting to "remember" this user.
>
> ** **
>
> And then it displays an error page "Sorry, an error occurred.  Please try
> again."
>
> ** **
>
> And then the end user tries again.  Sames steps to get another Proxy
> Ticket to the Untrusted Application.  This time the Untrusted Application
> presents that Proxy Ticket to the Institutional Web Service.
>
> ** **
>
> And now the Untrusted Application combines the user identity and the
> Institutional Web Service's data to break the anonymity.
>
> ** **
>
> The problem is that proxy tickets are fundamentally bearer tokens, and if
> they pass through the Untrusted Application, the Untrusted Application gets
> to be the bearer and can choose to itself redeem the ticket rather than
> presenting it to its intended recipient.  You can achieve the anonymity in
> the Untrusted Application that you seek by authenticating the Institutional
> Web Service when the Institutional Web Service gets the username.  That
> could either be by enhancing CAS to support client authentication on the
> validation request (i.e., proxy tickets stop being bearer tokens and start
> being redeemable only by their intended recipient) or by requiring the
> Institutional Web Service to itself get a PGT and use a PT with itself as
> the last authenticated proxy in the chain to get the username (proxy
> tickets remain bearer tokens, but the Untrusted Application never gets to
> bear a token that can be redeemed for a username).
>
> ** **
>
> Kind regards,
>
> ** **
>
> Andrew
>
> ** **
>
> ** **
>
> ** **
>
> On Fri, Jan 11, 2013 at 12:05 PM,  wrote:
>
> Andrew,
>
> Thanks for the feedback!  
>
> My idea was that the untrusted app has NO direct contact with CAS - it
> redirects to a campus page that redirects to cas (along with a parameter
> that specifies the untrusted app's URL so the campus page can redirect the
> user back to the untrusted app after the authentication with CAS).  CAS
> sends them back to the campus page which then sends the proxyticket as an
> argument in a redirect back to the untrusted app.  
>
> Untrusted App - > UCB Landing Page (which gets Untrusted App referrer URL)
> -> CAS (with referrer URL as parameter) -> UCB Landing Page (with referrer
> URL as parameter)  -- CAS call to get ProxyTicket -> Untrusted App (with
> ProxyTicket as parameter)
>
> To the user it looks like they're authenticating from the untrusted app
> but they're really authenticating to a campus page that it is doing all the
> heavy lifting and passing the proxyticket to the untrust

Re: [cas-user] Error in building cas

[Andrew Petro]

What happens if you delete this directory:

/Users/rraman/.m2/repository/junit

and then run the build?  That should cause Maven to download the dependency
again, and perhaps replace a broken local .jar file.




On Mon, Feb 4, 2013 at 2:41 PM, rewati raman  wrote:

> Hi There
> I am new to cas. I am investigating cas to use in my project for multiple
> app.
>
> when I run this command. 'mvn package install'
> I am getting this error.
> [INFO] 30 errors
> [INFO] -
> [INFO]
> 
> [ERROR] BUILD FAILURE
> [INFO]
> 
> [INFO] Compilation failure
>
> error: error reading
> /Users/rraman/.m2/repository/junit/junit/4.10/junit-4.10.jar; cannot
> read zip file
>
> /Users/rraman/Project/ParkSpot/cas-server-3.5.1/cas-server-support-ldap/src/test/java/org/jasig/cas/monitor/PoolingContextSourceMonitorTests.java:[24,16]
> package org.junit does not exist
>
> /Users/rraman/Project/ParkSpot/cas-server-3.5.1/cas-server-support-ldap/src/test/java/org/jasig/cas/monitor/PoolingContextSourceMonitorTests.java:[25,16]
> package org.junit does not exist
>
> /Users/rraman/Project/ParkSpot/cas-server-3.5.1/cas-server-support-ldap/src/test/java/org/jasig/cas/monitor/PoolingContextSourceMonitorTests.java:[26,23]
> package org.junit.runner does not exist
>
> /Users/rraman/Project/ParkSpot/cas-server-3.5.1/cas-server-support-ldap/src/test/java/org/jasig/cas/monitor/PoolingContextSourceMonitorTests.java:[32,23]
> package org.junit does not exist
>
> /Users/rraman/Project/ParkSpot/cas-server-3.5.1/cas-server-support-ldap/src/test/java/org/jasig/cas/monitor/PoolingContextSourceMonitorTests.java:[32,0]
> static import only from classes and interfaces
>
> /Users/rraman/Project/ParkSpot/cas-server-3.5.1/cas-server-support-ldap/src/test/java/org/jasig/cas/monitor/PoolingContextSourceMonitorTests.java:[40,1]
> cannot find symbol
> symbol: class RunWith
> @RunWith(SpringJUnit4ClassRunner.class)
>
> /Users/rraman/Project/ParkSpot/cas-server-3.5.1/cas-server-support-ldap/src/test/java/org/jasig/cas/util/LdapUtilTests.java:[22,22]
> package junit.framework does not exist
>
> /Users/rraman/Project/ParkSpot/cas-server-3.5.1/cas-server-support-ldap/src/test/java/org/jasig/cas/util/LdapUtilTests.java:[29,41]
> cannot find symbol
> symbol: class TestCase
> public final class LdapUtilTests extends TestCase {
>
> /Users/rraman/Project/ParkSpot/cas-server-3.5.1/cas-server-support-ldap/src/test/java/org/jasig/cas/authentication/principal/CredentialsToLDAPAttributePrincipalResolverTests.java:[21,16]
> package org.junit does not exist
>
> /Users/rraman/Project/ParkSpot/cas-server-3.5.1/cas-server-support-ldap/src/test/java/org/jasig/cas/authentication/principal/CredentialsToLDAPAttributePrincipalResolverTests.java:[25,23]
> package org.junit does not exist
>
> /Users/rraman/Project/ParkSpot/cas-server-3.5.1/cas-server-support-ldap/src/test/java/org/jasig/cas/adaptors/ldap/BindLdapAuthenticationHandlerTests.java:[24,23]
> package org.junit does not exist
>
> /Users/rraman/Project/ParkSpot/cas-server-3.5.1/cas-server-support-ldap/src/test/java/org/jasig/cas/adaptors/ldap/FastBindLdapAuthenticationHandlerTests.java:[24,23]
> package org.junit does not exist
>
> /Users/rraman/Project/ParkSpot/cas-server-3.5.1/cas-server-support-ldap/src/test/java/org/jasig/cas/monitor/PoolingContextSourceMonitorTests.java:[51,5]
> cannot find symbol
> symbol  : class Before
> location: class org.jasig.cas.monitor.PoolingContextSourceMonitorTests
>
> /Users/rraman/Project/ParkSpot/cas-server-3.5.1/cas-server-support-ldap/src/test/java/org/jasig/cas/monitor/PoolingContextSourceMonitorTests.java:[57,5]
> cannot find symbol
> symbol  : class Test
> location: class org.jasig.cas.monitor.PoolingContextSourceMonitorTests
>
> /Users/rraman/Project/ParkSpot/cas-server-3.5.1/cas-server-support-ldap/src/test/java/org/jasig/cas/monitor/PoolingContextSourceMonitorTests.java:[63,5]
> cannot find symbol
> symbol  : class Test
> location: class org.jasig.cas.monitor.PoolingContextSourceMonitorTests
>
> /Users/rraman/Project/ParkSpot/cas-server-3.5.1/cas-server-support-ldap/src/test/java/org/jasig/cas/authentication/principal/CredentialsToLDAPAttributePrincipalResolverTests.java:[57,5]
> cannot find symbol
> symbol  : class Test
> location: class
>
> org.jasig.cas.authentication.principal.CredentialsToLDAPAttributePrincipalResolverTests
>
> /Users/rraman/Project/ParkSpot/cas-server-3.5.1/cas-server-support-ldap/src/test/java/org/jasig/cas/authentication/principal/CredentialsToLDAPAttributePrincipalResolverTests.java:[67,5]
> cannot find symbol
> symbol  : class Test
> location: class
>
> org.jasig.cas.authentication.principal.CredentialsToLDAPAttributePrincipalResolverTests
>
> /Users/rraman/Project/ParkSpot/cas-server-3.5.1/cas-server-support-ldap/src/test/java/org/jasig/cas/monitor/PoolingContex

Re: [cas-user] google apps saml authentication via cas is failing for some users

[Andrew Petro]

The OAuth timeout problem, the SAML assertion timeout problem, and the CAS
service ticket problem, would all be solved by CAS issuing the [OAuth token
/ SAML assertion / service ticket] after the user clears the warning /
authorization screen hurdle.  The login flow can have as much user
experience interaction as it needs to have, several attribute release /
informed consent screens, whatever, so long as the CAS server issues the
token only when it is entirely ready to send the token along to the relying
party.

That should make 5s ST timeouts just fine.




On Thu, Feb 7, 2013 at 5:10 AM, jleleu  wrote:

> Hi,
>
> I'm not sure that the solution is to increase the timeout up to 30s (which
> I estimate too much for security and not enough for user interaction).
>
> I was considering that interrupt screens should rely on the web session
> lifetime (like the login page).
>
> Best regards,
> Jérôme
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] Google Apps and uPortal with SSO

[Andrew Petro]

Ed,

You seem to be thinking about the CAS server customization such that SSO
sessions are initiated only when logging in to the portal.  Otherwise,
applications can use CAS for login, but doing so doesn't create SSO
sessions.

This can be a nice approach in that it helps users to understand, think
about their single sign-on session, and helps them to understand where they
might go to explicitly log out to end it.

I get the idea that a customization to only begin an SSO session when
logging into the portal is decently common -- I believe Rutgers is or was
doing this in their CAS server, for instance; it's something Unicon's done,
I believe, and that comes up in our CAS implementation plannings.

Otherwise, you might simply want the portal to opt-out of itself benefiting
from single sign-on by setting renew=true.  Logging in to the portal would
still create an SSO session.  Logging into Google Apps would still create
an SSO session.  Logging in to Google Apps (or anything else) wouldn't
yield a single sign-on session useful for logging in to the portal, though
-- in all cases users would have to authenticate explicitly for the purpose
of logging into the portal, whenever they log in to the portal.

That requires no customization and might scratch your immediate itch.

Kind regards,

Andrew



On Fri, Feb 8, 2013 at 10:06 AM, Ed Hillis  wrote:

> We're integrating Google Apps with our CAS SSO, and we're also using
> uPortal. I'm trying to arrive at the right combination of availability and
> security, and would appreciate any thoughts.
>
> Currently, a user logged in to our portal can browse to mail.google.comand be 
> authenticated with their existing CAS ticket. That's fine. A user
> who is not logged in to the portal can browse to mail.google.com, be
> redirected to our CAS login, then redirected back to Google. The security
> problem is that then, given our SSO environment, they are also
> authenticated at the portal and will remain so until they close the
> browser, even though they never "visited" the portal.
>
> Other scenarios to get around the problem that I can imagine but am not
> sure how to implement:
>
> 1) The user only gets SSO authentication at Google if they already
> expressly logged in to the portal. Otherwise they must authenticate at
> Google, or perhaps be directed to the portal log in (log in to the portal,
> not just do CAS authentication).
>
> 2) If the user has not already expressly logged in to the portal, when
> they browse to mail.google.com, they go through CAS authentication but
> get a ticket that can only be used for Google -- i.e., they are not
> simultaneously authenticated in the portal.
>
> I'd appreciate hearing from others on this. Best practices? Did you go
> with a different arrangement? Am I overlooking some basic CAS setup that
> would solve the problem? I am new to both uPortal and CAS, so any level of
> advice here would be helpful.
>
> Thanks,
> Ed
>
> --
> Ed Hillis, Web Programmer
> Southwestern University
> 1001 East University Avenue, Georgetown, TX 78626
> 512.863.1066 hill...@southwestern.edu
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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] Single-Sign-on Session Time Out

[Andrew Petro]

There's no out of the box configuration for differing the single sign-on
session length per relying party, but it wouldn't be hard to customize CAS
to do this, especially if what you mean is that each application has a
different time threshold after which it considers a single sign-on session
too stale for its purposes and wishes CAS to again prompt the user to login
with password.

I'd suggest some skepticism as to whether this is a good idea.  Single
sign-on session duration is hard enough for users to relate to without the
effective duration differing continuously.

In projects I've been involved in, it's often been all-or-nothing -- some
applications participate in SSO, and some never participate in SSO, via the
CAS "renew" feature on the login request.




On Mon, Feb 11, 2013 at 4:31 AM, jleleu  wrote:

> Hi,
>
> To be simple, you have two kinds of timeout :
> - the one of your SSO session
> - the ones of your web applications.
>
> The SSO timeout is configured in CAS server where as application timeouts
> are configured their own way in each web application.
>
> Best regards,
> Jérôme
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] Different Set of users for different application

[Andrew Petro]

You might also choose to implement Fordham-style coarse grained access
control at the CAS server layer, such that CAS is aware of whether a given
user is in a given target application's acceptable user set and blocks
attempts to login to applications the user is not permitted to access,
preferably with a friendly error experience.

cf. presentation at the most recent Jasig-Sakai conference on this topic,
recording available.


On Mon, Feb 11, 2013 at 4:27 AM, jleleu  wrote:

> Hi,
>
> You can have several applications participating in the SSO, with different
> set of attributes of the authenticated user for each applications.
> The user attributes returned to the web application by the CAS server
> (during the service ticket validation) can be configured in the CAS server
> back office : https://wiki.jasig.org/display/CASUM/Services+Management,
> https://wiki.jasig.org/display/CASUM/Attributes.
> Best regards,
> Jérôme
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] Tomcat container CAS questions

[Andrew Petro]

If your web service was *only* going to use those attributes for coarse
grained authorization, then you might consider implementing coarse-grained
attribute-driven access control within the CAS server such that only users
with appropriate attributes are able to obtain tickets for authentication
to your web service.  That would let you dodge having to consume user
attributes from CAS in your web service implementation itself.

While Tomcat Realm is one way to integrate to rely upon CAS in your Java
web application, it's by no means the only available strategy.  Fronting
with Apache httpd and using mod_auth_cas.  Apache Shiro.  Spring Security.
 Java CAS Client filters in web.xml.  Any of that might give you a path to
accepting proxy tickets.

I do agree the Tomcat integration components ought to evolve to accept
Proxy Tickets, and that that evolution wouldn't be a big lift.

Kind regards,

Andrew


On Wed, Feb 13, 2013 at 9:15 AM, Marvin Addison wrote:

> >  I don't understand the last example
> > "Leveraging Attribute Release for Role Data". Would that allow me not to
> > have to specify the users?
>
> Yes. You'd need to release attributes to the service, which are
> typically delivered by SAML 1.1. Then you can specify the name of the
> attribute that contains role names that will be subsequently used for
> protecting resource URIs. The following would go in the context
> descriptor, for example:
>
>className="org.jasig.cas.client.tomcat.v6.AssertionCasRealm"
> roleAttributeName="member"
> />
>className="org.jasig.cas.client.tomcat.v6.Saml11Authenticator"
> encoding="UTF-8"
> casServerLoginUrl="https:/cas.example.com/cas/login"
> casServerUrlPrefix="https:/cas.example.com/"
> serverName="cas-client.example.com"
> />
>
> You would then leverage role names for access control as normal in Tomcat:
>
>   
> 
>member=farmers,ou=Groups,dc=berkeley,dc=edu
> 
> 
>   CONFIDENTIAL
> 
>   
>
>   
> SAML11
>   
>
>   
> 
>   The role that is required to log in to the Manager Application
> 
> member=farmers,ou=Groups,dc=berkeley,dc=edu
>   
>
> > A further complication is that since my web app is a service, it would
> > need to accept CAS proxy tickets. How would THAT work with users and
> roles?
>
> Proxy is not supported by the Tomcat integration components. It can
> probably be done without too much work. Patches welcome.
>
> M
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] Authentication Failure

[Andrew Petro]

Hi,

That's a weird behavior, that it fails initially and then works.  I don't
have an explanation for that off hand.

Are there corresponding log entries from the CAS server wherein the server
explains why it is responding with a 500 status code?

Otherwise:

1) Do you get the failure behavior when manually exercising the ticket
validation?  As in, turn up ST timeouts, manually obtain an ST, manually
validate it, in your browser.

2) Why /cas/proxyValidate ?  If the application validating the ST intends
only to accept service tickets and not proxy tickets, it's preferable to
use the /cas/serviceValidate endpoint so as to avoid accidentally accepting
a proxy ticket.  Note that /cas/proxyValidate is necessary only to
*validate* a proxy ticket, not just to obtain a PGT.

3) Try cranking up Java CAS client logging to TRACE to get more context.
 Likewise, crank up logging on the CAS server.

Hope this helps,

Andrew






On Mon, Feb 25, 2013 at 7:14 AM, E.LT  wrote:

> Hello everyone and thanks in advance for your time !
>
> I'm having problems authenticating uportal to CAS.
>
> Every first authentication is failing and i don't know why.
>
> I'm having a Tomcat 500 error and when i try to retry the uportal URL it's
> ok. I really don't understand why it behaves like this. Only the first
> authentication fails. then you can chain disconnect / reconnect successfuly.
>
> Here's the web error message :
>
>
>
>
> exception
>
> java.lang.RuntimeException: java.io.IOException: Server returned HTTP
> response
> code: 500 for URL:
>
> https://sso-cas.xxx.fr/cas/proxyValidate?pgtUrl=http%3A%2F%2Fent1.xxx.fr%2FCasProxyServlet&ticket=ST-350-NzDBiGHm4WIBGqq4nxUV-cas&service=http%3A%2F%2Fent1.xxx.fr%2FLogin
>
>
> org.jasig.cas.client.util.CommonUtils.getResponseFromServer(CommonUtils.java:295)
>
>
> org.jasig.cas.client.validation.AbstractCasProtocolUrlBasedTicketValidator.retrieveResponseFromServer(AbstractCasProtocolUrlBasedTicketValidator.java:33)
>
>
> org.jasig.cas.client.validation.AbstractUrlBasedTicketValidator.validate(AbstractUrlBasedTicketValidator.java:178)
>
>
> org.jasig.cas.client.validation.AbstractTicketValidationFilter.doFilter(AbstractTicketValidationFilter.java:132)
> cause mère
>
> java.io.IOException: Server returned HTTP response code: 500 for URL:
>
> https://sso-cas.xxx.fr/cas/proxyValidate?pgtUrl=http%3A%2F%2Fent1.xxx.fr%2FCasProxyServlet&ticket=ST-350-NzDBiGHm4WIBGqq4nxUV-cas&service=http%3A%2F%2Fent1.xxx.fr%2FLogin
>
>
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1436)
>
>
> com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnectionOldImpl.getInputStream(HttpsURLConnectionOldImpl.java:204)
>
>
> org.jasig.cas.client.util.CommonUtils.getResponseFromServer(CommonUtils.java:281)
>
>
> org.jasig.cas.client.validation.AbstractCasProtocolUrlBasedTicketValidator.retrieveResponseFromServer(AbstractCasProtocolUrlBasedTicketValidator.java:33)
>
>
> org.jasig.cas.client.validation.AbstractUrlBasedTicketValidator.validate(AbstractUrlBasedTicketValidator.java:178)
>
>
> org.jasig.cas.client.validation.AbstractTicketValidationFilter.doFilter(AbstractTicketValidationFilter.java:132
>
>
> I'm really lost ..
>
> Thanks a lot (And sorry for the faults :()
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] Authentication Failure

[Andrew Petro]

Hi,

Oh dear.  These things do tend to happily work well for months and months
until they don't.

Ok.  The Granted bit is a good sign.  However, that happens when the end
user interacts with /cas/login .  The failure you're seeing happens when
your application interacts with /cas/proxyValidate to validate a ticket.
 There should be corresponding audit log entries for the ticket validation
attempt.

Except there won't be, given that stack trace you've posted.  It looks like
the audit trail system itself is failing, for lack of a
"resourceOperatedOn" to log.

What version of Inspektr are you using?  For that matter, what version of
CAS are you using?  You can determine the versions of both of these by
looking at the .jar files in /WEB-INF/lib -- say, cas-server-core for the
CAS version and something inspektr for the Inspektr version.

This issue sounds familiar to me.  I think something like this came up
before and led to better diagnostics in the latest Inspektr release.

https://github.com/dima767/inspektr/issues/13

https://github.com/dima767/inspektr/commit/a7c9187fc59db572478929508e0f90bb2ec12da6

If you're on a back version, you might try bumping up to the 1.0.7 version
and see if it helps or at least you get better errors in the log.

http://mvnrepository.com/artifact/com.github.inspektr/inspektr

Kind regards,

Andrew




On Mon, Feb 25, 2013 at 10:10 AM, E.LT  wrote:

> Hello,
>
> Thank you for your answer.
>
> Unfortunatly, i don't know how to exactly make the changes you're asking.
>
> I don't know why it asks for a PGT. When i'm having this error, i can find
> (i've put debug mode for logs) that i'm getting a Service Ticket
>
> " Granted service ticket [ST-744-DA4yHAXUv6a2xxMJgpdOr9-cas] for service [
> http://ent2.xxx.fr/Login] for user [xxx]"
>
> Yet, it still displays the HTTP 500 error.
>
> On the catalina.out, i do have a trace :
>
> "25 févr. 2013 16:09:55 org.apache.catalina.core.StandardWrapperValve
> invoke
> GRAVE: "Servlet.service()" pour la servlet cas a généré une exception
> java.lang.IllegalArgumentException: resourceOperatedUpon cannot be null
> at
> com.github.inspektr.audit.AuditActionContext.assertNotNull(AuditActionContext.java:81)
> at
> com.github.inspektr.audit.AuditActionContext.(AuditActionContext.java:64)
> at
> com.github.inspektr.audit.AuditTrailManagementAspect.executeAuditCode(AuditTrailManagementAspect.java:148)
> at
> com.github.inspektr.audit.AuditTrailManagementAspect.handleAuditTrail(AuditTrailManagementAspect.java:139)
> at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621)
> at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610)
> at
> org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at
> org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80)
> at
> org.perf4j.aop.AbstractTimingAspect$1.proceed(AbstractTimingAspect.java:47)
> at
> org.perf4j.aop.AgnosticTimingAspect.runProfiledMethod(AgnosticTimingAspect.java:44)
> at
> org.perf4j.aop.AbstractTimingAspect.doPerfLogging(AbstractTimingAspect.java:45)
> at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621)
> at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610)
> at
> org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)
> at $Proxy44.delegateTicketGrantingTicket(Unknown Source)
> at
> org.jasig.cas.web.ServiceValidateController.handleRequestInternal(ServiceValidateController.java:127)
> at
> org.springframework.web.servlet.mvc.AbstractController.han

Re: [cas-user] Authentication Failure

[Andrew Petro]

Incidentally and more strategically for Inspektr, it might be worth
revisiting the assertions to make unexpected inputs to the audit trail
logging not induce failure in the functionality being logged.

Captured thought to issue #16 in the Inspektr project.

https://github.com/dima767/inspektr/issues/16


On Mon, Feb 25, 2013 at 10:50 AM, Andrew Petro  wrote:

> Hi,
>
> Oh dear.  These things do tend to happily work well for months and months
> until they don't.
>
> Ok.  The Granted bit is a good sign.  However, that happens when the end
> user interacts with /cas/login .  The failure you're seeing happens when
> your application interacts with /cas/proxyValidate to validate a ticket.
>  There should be corresponding audit log entries for the ticket validation
> attempt.
>
> Except there won't be, given that stack trace you've posted.  It looks
> like the audit trail system itself is failing, for lack of a
> "resourceOperatedOn" to log.
>
> What version of Inspektr are you using?  For that matter, what version of
> CAS are you using?  You can determine the versions of both of these by
> looking at the .jar files in /WEB-INF/lib -- say, cas-server-core for the
> CAS version and something inspektr for the Inspektr version.
>
> This issue sounds familiar to me.  I think something like this came up
> before and led to better diagnostics in the latest Inspektr release.
>
> https://github.com/dima767/inspektr/issues/13
>
>
> https://github.com/dima767/inspektr/commit/a7c9187fc59db572478929508e0f90bb2ec12da6
>
> If you're on a back version, you might try bumping up to the 1.0.7 version
> and see if it helps or at least you get better errors in the log.
>
> http://mvnrepository.com/artifact/com.github.inspektr/inspektr
>
> Kind regards,
>
> Andrew
>
>
>
>
> On Mon, Feb 25, 2013 at 10:10 AM, E.LT  wrote:
>
>> Hello,
>>
>> Thank you for your answer.
>>
>> Unfortunatly, i don't know how to exactly make the changes you're asking.
>>
>> I don't know why it asks for a PGT. When i'm having this error, i can
>> find (i've put debug mode for logs) that i'm getting a Service Ticket
>>
>> " Granted service ticket [ST-744-DA4yHAXUv6a2xxMJgpdOr9-cas] for service [
>> http://ent2.xxx.fr/Login] for user [xxx]"
>>
>> Yet, it still displays the HTTP 500 error.
>>
>> On the catalina.out, i do have a trace :
>>
>> "25 févr. 2013 16:09:55 org.apache.catalina.core.StandardWrapperValve
>> invoke
>> GRAVE: "Servlet.service()" pour la servlet cas a généré une exception
>> java.lang.IllegalArgumentException: resourceOperatedUpon cannot be null
>> at
>> com.github.inspektr.audit.AuditActionContext.assertNotNull(AuditActionContext.java:81)
>> at
>> com.github.inspektr.audit.AuditActionContext.(AuditActionContext.java:64)
>> at
>> com.github.inspektr.audit.AuditTrailManagementAspect.executeAuditCode(AuditTrailManagementAspect.java:148)
>> at
>> com.github.inspektr.audit.AuditTrailManagementAspect.handleAuditTrail(AuditTrailManagementAspect.java:139)
>> at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at
>> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621)
>> at
>> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610)
>> at
>> org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65)
>> at
>> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
>> at
>> org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80)
>> at
>> org.perf4j.aop.AbstractTimingAspect$1.proceed(AbstractTimingAspect.java:47)
>> at
>> org.perf4j.aop.AgnosticTimingAspect.runProfiledMethod(AgnosticTimingAspect.java:44)
>> at
>> org.perf4j.aop.AbstractTimingAspect.doPerfLogging(AbstractTimingAspect.java:45)
>> at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at
>> org.springframe

Re: [cas-user] Assistance needed adding JSON presistance to cas

[Andrew Petro]

Rick,

So, up a few levels of abstraction.

You need to use a version of cas-addons that's compatible with the version
of cas-server-webapp you're building on.

So, what version of cas-server-webapp are you overlaying upon and what
version of cas-addons are you depending upon?

(And then if you say anything other than the latest version of each, of
course, I'm going to suggest using the latest versions. :) )

Andrew




On Mon, Feb 25, 2013 at 10:23 AM, Richard Versace wrote:

> Misagh,
>
> Thanks for the hint, but as I said, I'm sort of coming in in the middle of
> the movie and that doesn't mean much to me right now.
>
> Could you give me another hint or point me to some documentation somewhere
> that could help me out?
>
> Thanks,
>
> Rick.
>
>
>
> On Mon, Feb 25, 2013 at 9:50 AM, Misagh Moayyed wrote:
>
>> Seems like the ‘c’ namespace is part of Spring 3.1. You could try the
>> alternative syntax that is: 
>>
>> ** **
>>
>> *-*Misagh*
>>
>> *
>>
>> ** **
>>
>> *From:* Richard Versace [mailto:rivers...@vassar.edu]
>> *Sent:* Saturday, February 23, 2013 3:03 PM
>> *To:* cas-user@lists.jasig.org
>> *Subject:* Re: [cas-user] Assistance needed adding JSON presistance to
>> cas
>>
>> ** **
>>
>> Based on this...
>>
>>
>> >locate spring|grep tomcat|grep WEB-INF|grep -i release|grep jar|sort -u
>>
>>
>> /opt/tomcat6/apache-tomcat-6.0.35/webapps/cas/WEB-INF/lib/spring-aop-3.0.5.RELEASE.jar
>>
>> /opt/tomcat6/apache-tomcat-6.0.35/webapps/cas/WEB-INF/lib/spring-asm-3.0.5.RELEASE.jar
>>
>> /opt/tomcat6/apache-tomcat-6.0.35/webapps/cas/WEB-INF/lib/spring-beans-3.0.5.RELEASE.jar
>>
>> /opt/tomcat6/apache-tomcat-6.0.35/webapps/cas/WEB-INF/lib/spring-binding-2.2.1.RELEASE.jar
>> 
>>
>> I'd say 3.0.5.  But it's just a guess
>>
>> ** **
>>
>> On Sat, Feb 23, 2013 at 5:09 AM, Misagh Moayyed 
>> wrote:
>>
>> Rick, could you explain what Spring version you’re using in your Maven
>> overlay? 
>>
>>  
>>
>> *-*Misagh
>>
>>  
>>
>> *From:* Richard Versace [mailto:rivers...@vassar.edu]
>> *Sent:* Thursday, February 21, 2013 9:53 AM
>> *To:* cas-user@lists.jasig.org
>> *Subject:* [cas-user] Assistance needed adding JSON presistance to cas***
>> *
>>
>>  
>>
>> Firstly, I'm new to the wild and wonderful world of server side java apps
>> and alI of the configuration and other magic that goes along with it.
>>
>>  
>>
>> Secondly, I have a cas setup that consists of 2 load balanced nodes that
>> keep ticket info current using ehcache.
>>
>>  
>>
>> Thirdly, I'm trying to add persistence to the services registry using the
>> JSON method found here...
>> https://github.com/Unicon/cas-addons/wiki/Configuring-JSON-Service-Registry
>> 
>>
>>  
>>
>>  
>>
>> I've muddled my way through most of the setup but now I'm stuck, I'm sure
>> not for the last time.
>>
>>  
>>
>> this line in deployerConfigContext.xml is giving me trouble...
>>
>>  
>>
>> xmlns:c="http://www.springframework.org/schema/c"
>>
>>  
>>
>> This assumption is based on this line in the catalina.out file at
>> startup...
>>
>>  
>>
>> 2013-02-21 11:01:49,880 ERROR
>> [org.springframework.web.context.ContextLoader] - > failed>
>>
>> org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
>> Configuration problem: Unable to locate Spring NamespaceHandler for XML
>> schema namespace [http://www.springframework.org/schema/c]
>>
>> Offending resource: ServletContext resource
>> [/WEB-INF/deployerConfigContext.xml]
>>
>>  
>>
>> Based on the blind research I've done I'm thinking I don't have the
>> proper version of Spring.  I haven't a clue on how to fix that.
>>
>>  
>>
>> I am using maven 2.? to package the war file.  
>>
>>  
>>
>> Don't know what other info anyone may need because, like I said, I'm new
>> to this magic.
>>
>>  
>>
>> Any help would be appreciated.
>>
>>  
>>
>> Thanks,
>>
>>  
>>
>> Rick Versace.
>>
>>  
>>
>> --
>> 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: 
>> rivers...@vassar.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: 
>> 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: 
>> rivers...@vassar.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: ape...@unicon.net
> To unsub

Re: [cas-user] Authentication Failure

[Andrew Petro]

E.,

Your portal is asking that CAS call it back with a PGT, yes, but otherwise
the PGT shouldn't be relevant.  If the CAS server proxy callback fails,
then CAS will issue the ST anyway and omit the PGTIOU from the ST
validation response.  Maybe the PGT callback is inserting enough delay to
run afoul of that 10 second timeout.

Incidentally, your portal's login URL and proxy callback URL aren't using
https.  The former is poor practice, and the latter just shouldn't work.

But anyway, as a next thing to try: how about nudging up the service ticket
timeout to 30 seconds rather than 10 seconds and see if anything changes?

Andrew





On Mon, Feb 25, 2013 at 11:08 AM, E.LT  wrote:

> Hello,
>
> I just removed the file you asked and i got different results. Here's the
> web http 500 error :
>
> "exception
>
> javax.servlet.ServletException:
> org.jasig.cas.client.validation.TicketValidationException:
> the ticket 'ST-14-o6h5Xx1BDhb1CPUQsT7Y-cas' is unknown
>
>
> org.jasig.cas.client.validation.AbstractTicketValidationFilter.doFilter(AbstractTicketValidationFilter.java:155)
>
>
> cause mère
>
> org.jasig.cas.client.validation.TicketValidationException:
> the ticket 'ST-14-o6h5Xx1BDhb1CPUQsT7Y-cas' is unknown
>
>
> org.jasig.cas.client.validation.Cas20ServiceTicketValidator.parseResponseFromServer(Cas20ServiceTicketValidator.java:73)
>
> org.jasig.cas.client.validation.AbstractUrlBasedTicketValidator.validate(AbstractUrlBasedTicketValidator.java:188)
>
> org.jasig.cas.client.validation.AbstractTicketValidationFilter.doFilter(AbstractTicketValidationFilter.java:132)
>
> "
>
>
>
> And in the cas.log :
>
> "2013-02-25 17:01:07,861 INFO
> [org.jasig.cas.CentralAuthenticationServiceImpl] - Granted service ticket
> [ST-14-o6h5Xx1BDhb1CPUQsT7Y-cas] for service [http://ent2..fr/Login]
> for user [x]
> 2013-02-25 17:01:07,974 INFO
> [org.jasig.cas.authentication.AuthenticationManagerImpl] -
> AuthenticationHandler:
> org.jasig.cas.adaptors.ldap.BindLdapAuthenticationHandler failed to
> authenticate the user which provided the following credentials: [username:
> id3367]
> 2013-02-25 17:01:17,883 INFO
> [org.jasig.cas.authentication.AuthenticationManagerImpl] -
> AuthenticationHandler:
> org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler
> successfully authenticated the user which provided the following
> credentials: [callbackUrl: http://ent2.xxx.fr/CasProxyServlet]
> 2013-02-25 17:01:17,884 ERROR
> [org.jasig.cas.web.ServiceValidateController] - TicketException generating
> ticket for: [callbackUrl: http://ent2.xxx.fr/CasProxyServlet]
> org.jasig.cas.ticket.InvalidTicketException
> at
> org.jasig.cas.CentralAuthenticationServiceImpl.delegateTicketGrantingTicket_aroundBody6(CentralAuthenticationServiceImpl.java:278)
> at
> org.jasig.cas.CentralAuthenticationServiceImpl.delegateTicketGrantingTicket_aroundBody7$advice(CentralAuthenticationServiceImpl.java:44)
> at
> org.jasig.cas.CentralAuthenticationServiceImpl.delegateTicketGrantingTicket(CentralAuthenticationServiceImpl.java:1)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at
> org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80)
> at
> org.perf4j.aop.AbstractTimingAspect$1.proceed(AbstractTimingAspect.java:47)
> at
> org.perf4j.aop.AgnosticTimingAspect.runProfiledMethod(AgnosticTimingAspect.java:44)
> at
> org.perf4j.aop.AbstractTimingAspect.doPerfLogging(AbstractTimingAspect.java:45)
> at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621)
> at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610)
> at
> org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at
> org.springframework.aop.interceptor.Ex

Re: [cas-user] Assistance needed adding JSON presistance to cas

[Andrew Petro]

Rick,

It can be that easy.

It can be more difficult.

Besides nudging the metadata in your pom.xml, it's also a matter of looking
at every file in your local overlay and comparing it with the latest in CAS
and considering the differences in the vanilla CAS 3.4.12 and vanilla CAS
3.5.1 versions.  As in, if the vanilla file changed, you might want to
apply something like that change locally, or you might want to delete your
local file, pull down the copy from CAS 3.5.1, and edit it anew.  In some
cases "might want" becomes "you must do this or it won't work" -- things
are allowed to change between a 3.4 and a 3.5 version.

But in general, yes, the Maven overlay practice is supposed to make
upgrades easier by minimizing your local source files down to just the ones
that are unique and special to your environment and making the version of
the product you're overlaying upon a matter of declarative configuration in
pom.xml.

Hope this helps,

Andrew




On Mon, Feb 25, 2013 at 2:04 PM, Richard Versace wrote:

> So it was as easy as changing...
>
> 
> 3.4.12
> 1.5.6
> 2.5.0
> 1.0
> 
>
>
> to...
>
> 
> 3.5.1
> 1.5.6
> 2.5.0
> 1.2
> 
>
> in the pom.xml file and it all works like magic???
>
> Or did I miss something?
>
>
> On Mon, Feb 25, 2013 at 11:59 AM, Richard Versace wrote:
>
>> Dmitriy,
>>
>> Thanks for all of that.  Now I need to figure out what to do with it.  :o)
>>
>> If anyone can post anything that points to tips, tricks, posts about
>> doing upgrades I would appreciate it.
>>
>> I guess the first time is always the hardest.
>>
>> Thanks again and in advance,
>>
>> Rick.
>>
>>
>>
>> On Mon, Feb 25, 2013 at 11:49 AM, Dmitriy Kopylenko <
>> dmitriy.kopyle...@gmail.com> wrote:
>>
>>> Rick,
>>>
>>> your overlay currently builds on top of CAS 3.4.12. The minimum
>>> supported version of CAS for cas-addons 1.0 and up is 3.5.1, as stated
>>> here: https://github.com/Unicon/cas-addons/blob/master/README.md
>>>
>>> So, I'm afraid that an upgrade would be in order here (which is a good
>>> thing in of itself).
>>>
>>> As for upgrade guidelines, I am not sure that there are any written ones
>>> (someone could correct me). The biggest thing to watch for during the
>>> upgrade would be that any custom components re-defined in CAS configuration
>>> files e.g. login-webflow.xml, cas-servlet.xml, deployerConfigContext.xml
>>> get properly ported into the newest configuration files from the CAS
>>> version in question.
>>>
>>> Cheers,
>>> Dmitriy.
>>>
>>>
>>>
>>> On Mon, Feb 25, 2013 at 10:59 AM, Richard Versace 
>>> wrote:
>>>
 Here you go.


 On Mon, Feb 25, 2013 at 10:33 AM, Dmitriy Kopylenko <
 dkopyle...@unicon.net> wrote:

> Hi Rick.
>
> Can you please send the pom.xml of your CAS overlay?
>
> Thanks,
> Dmitriy.
>
> On Feb 25, 2013, at 10:23 AM, Richard Versace 
> wrote:
>
> Misagh,
>
> Thanks for the hint, but as I said, I'm sort of coming in in the
> middle of the movie and that doesn't mean much to me right now.
>
> Could you give me another hint or point me to some documentation
> somewhere that could help me out?
>
> Thanks,
>
> Rick.
>
>
>
> On Mon, Feb 25, 2013 at 9:50 AM, Misagh Moayyed 
> wrote:
>
>> Seems like the ‘c’ namespace is part of Spring 3.1. You could try the
>> alternative syntax that is: *
>> ***
>>
>> ** **
>>
>> *-*Misagh*
>>
>> *
>>
>> ** **
>>
>> *From:* Richard Versace [mailto:rivers...@vassar.edu]
>> *Sent:* Saturday, February 23, 2013 3:03 PM
>> *To:* cas-user@lists.jasig.org
>> *Subject:* Re: [cas-user] Assistance needed adding JSON presistance
>> to cas
>>
>> ** **
>>
>> Based on this...
>>
>>
>> >locate spring|grep tomcat|grep WEB-INF|grep -i release|grep jar|sort
>> -u
>>
>>
>> /opt/tomcat6/apache-tomcat-6.0.35/webapps/cas/WEB-INF/lib/spring-aop-3.0.5.RELEASE.jar
>>
>> /opt/tomcat6/apache-tomcat-6.0.35/webapps/cas/WEB-INF/lib/spring-asm-3.0.5.RELEASE.jar
>>
>> /opt/tomcat6/apache-tomcat-6.0.35/webapps/cas/WEB-INF/lib/spring-beans-3.0.5.RELEASE.jar
>>
>> /opt/tomcat6/apache-tomcat-6.0.35/webapps/cas/WEB-INF/lib/spring-binding-2.2.1.RELEASE.jar
>> 
>>
>> I'd say 3.0.5.  But it's just a guess
>>
>> ** **
>>
>> On Sat, Feb 23, 2013 at 5:09 AM, Misagh Moayyed 
>> wrote:
>>
>> Rick, could you explain what Spring version you’re using in your
>> Maven overlay? 
>>
>>  
>>
>> *-*Misagh
>>
>>  
>>
>> *From:* Richard Versace [mailto:rivers...@vassar.edu]
>> *Sent:* Thursday, February 21, 2013 9:53 AM
>> *To:* cas-user@lists.jasig.org
>> *Subject:* [cas-user] Assistance needed adding JSON presistance to
>> cas
>>
>>  *

Re: [cas-user] CAS 4.0 / SAML 2.0

[Andrew Petro]

CAS 4.0 is not released, no.

There is, however, a *fantastic* free and open source software plugin for
CAS, implemented in Java, and compatibly licensed, implementing
excruciatingly rigorous, correct, excellent, careful, thoughtful SAML
support, both SAML1 and SAML2, supporting common profiles, IdP-initiated
and SP-initiated, with flexible configuration options, support for
federations, etc.  It's really quite good.

It's called the Shibboleth IdP.

http://shibboleth.net/products/identity-provider.html

And then you bridge to the Shibboleth IdP using this lovely integration
library, so that users experience CAS as the UI for login even when
integrating using SAML, and so that the SAML IdP and the traditional CAS
protocol share a single sign-on session, and so that forceAuthentication
can be honored correctly, etc.

https://github.com/Unicon/shib-cas-authenticator

You may find that CAS 3.5.2, with the Shibboleth IdP, with the CAS
integration plugin for the Shibboleth IdP, implements all the SAML support
you need. :)

Think of it as CAS 4 today, to the extent that you're looking for SAML
capabilities in a next CAS release.  Or, if you like, as Shibboleth IdPv3
today, since one new feature intended in Shibboleth IdP v3 is flexible
login workflow implemented with Spring Web Flow, which CAS offers today.

In all seriousness, Unicon has been successful in helping numerous adopters
happily implement this combination of CAS and Shibboleth IdP to realize CAS
login experience and lightweight protocol excellence, SAML rigor
excellence, all working well together in a shared single sign-on session
with a unified end-user-facing experience.

The future is now.

Hope this helps,

Andrew


On Tue, Feb 26, 2013 at 10:07 AM, Stein, Eric  wrote:

> According to this page, https://wiki.jasig.org/display/CAS/CAS+Roadmap,
> CAS 4.0 was targeted for release in Jan 2013. I can't find any
> indication that it has been released yet. Can you please confirm that it
> has not? I know it's not on the download page, but my boss keeps telling
> me it's out and we should be using it.
>
> He wants 4.0 for SAML 2.0 support. I've read* that CAS 3.5.1 has limited
> support for SAML 2.0. Is that true? If we can only viably support SAML
> 1.1 for now, that might be okay.
>
> As far as implementing SAML 1.1 with CAS 3.5.1, these are the
> documentation links I found .. did I miss anything?
> https://wiki.jasig.org/display/CASUM/SAML+Support+in+CAS+4
>
> https://wiki.jasig.org/display/CASUM/SAML+1.1
> https://wiki.jasig.org/display/CASC/Saml11TicketValidationFilter+Example
>
> https://sp.princeton.edu/oit/sdp/CAS/Wiki%20Pages/CAS%20samlValidate%20w
> alkthrough.aspx
>
>
> Thanks,
> Eric Stein
>
>
>
> *
> http://technotes.khitrenovich.com/cas-3-5-1-saml-2-0-identity-provider/,
> and others.
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] Presentation of CAS at Devoxx France 2013

[Andrew Petro]

Au contraire, je suis très intéressé.

Looks like a great presentation.

Will it be recorded?

I hope you'll be able to share slideware, and if you'd be interested in
making an English translation or even a recording of an English version of
the talk available, I think that would be wonderful and I'd be elated to
help you with that if I can.

Congratulations on making the conference schedule,

Andrew



On Thu, Feb 28, 2013 at 5:36 AM, jleleu  wrote:

> Hi,
>
> This will only interests French guys, but I will present CAS at Devoxx
> France : http://www.devoxx.com/display/FR13/CAS%2C+un+SSO+web+open+source.
> Best regards,
> Jérôme
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] Public computer login and CAS

[Andrew Petro]

I believe this is a well-known issue.

Modern browsers take liberties with their interpretation of the duration of
session-scoped cookies, such that merely closing the web browser is no
longer sufficient.

Users need to either explicitly log out of CAS to end their single sign-on
session and out of your application to end their session with your
application, or explicitly log out of their operating system desktop
session to prevent others from accessing it.  The latter is far preferable.

You can try to make explicit logout from CAS have a side effect of single
logout callbacks to your application to also log the user out of the
application, but this doesn't address the root issue of there being a
window of time within which the end user has valid session cookies that the
browser did not clean up on browser close such that re-opening the browser
can resurrect them.

Known shared browser installs can and should be configured to implement a
tighter understanding of what a session cookie's duration ought to be.  To
the extent that you're curating browser installs for, say, known-shared
computers in computer labs on a campus, those browser installs should be so
configured.  Internet cafe purveyors ought to do this.  Most probably
don't.  Then again, I just assume that all Internet cafe computers are
equipped with at least one malware keystroke logger. [1]

Otherwise, end users really really should be afforded the opportunity to
fully log out of their operating system sessions, and should do so when
leaving a shared computer.



[1]: A quick Google search suggests I'm not far off -- four out of ten
internet cafes providing keystroke loggers with their lattes in this one
study.  http://www.jiti.net/v11/jiti.v11n3.169-182.pdf




On Thu, Feb 28, 2013 at 2:08 PM, Ohsie, David  wrote:

> Do you have "Remember Me" turned on?
>
> ** **
>
> If not, it is possible that either the session cookies from your site are
> persistent (with an an explicit Expires/MaxAge) or else the cache control
> headers are allowing some pages to remain withing the browser cache.
>
> ** **
>
> *From:* Danny Sinang [mailto:d.sin...@gmail.com]
> *Sent:* Thursday, February 28, 2013 12:55 PM
> *To:* cas-user@lists.jasig.org
> *Subject:* [cas-user] Public computer login and CAS
>
> ** **
>
> Hi,
>
> ** **
>
> I noticed that closing and reopening my browser allows me to access
> protected webpages on my CASified site.
>
> ** **
>
> This could be a problem if I logged in from a public computer (internet
> cafe, etc).
>
> ** **
>
> Is there a way to secure against this ?
>
> ** **
>
> Regards,
> Danny
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: 
> david.oh...@emc.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] Public computer login and CAS

[Andrew Petro]

been thinking through potential Apereo conference session proposals.

It's this kind of browser behavior I had in mind when drafting this, which
I rather like:

Title: The Thrill of The Hunt - Tracking and Terminating Single Sign-On
Sessions in CAS and Shibboleth

Abstract: An exploration of concepts in, existing functionality for, and
good practices in tracking and terminating single sign-on sessions, in CAS
(the Central Authentication Service) and Shibboleth. By "tracking", think
Google Analytics and within-SSO-application functionality. By
"terminating", think logout, single logout, browser closing, operating
system session ending, hard drive reformatting, and high atmosphere
electromagnetic pulses. The latter isn't a best practice, but the
demonstration of out-of-the-box browser behaviors around secure session
management may drive you to consider it.


This sound like a presentation worth having at Apereo 2013?

Andrew



On Thu, Feb 28, 2013 at 4:28 PM, Ohsie, David  wrote:

> I agree with Andrew that if the browser is doing that, then there is
> probably nothing on the server side that you can do to fix it.   And
> recently I've been more chrome focused, so I probably missed the firefox
> change.  I'm going to do some testing now...
>
> Thanks to both Andrews for the explanation.
>
> david
>
> -Original Message-
> From: Andrew Morgan [mailto:mor...@orst.edu]
> Sent: Thursday, February 28, 2013 3:30 PM
> To: cas-user@lists.jasig.org
> Subject: RE: [cas-user] Public computer login and CAS
>
> Sometime around Firefox 15 or 16, the behavior changed.  If you close
> Firefox by clicking the [X] button on the window, when you re-open Firefox
> all of your session cookies are still present.  If you close Firefox by
> choosing File > Quit, when you re-open Firefox the cookies are gone.
> However, if you choose History > Restore Previous Session, then all the
> cookies and pages are restored.
>
> If you know of a server-side way to prevent this, I'd love to hear it!
>
> Andy
>
> On Thu, 28 Feb 2013, Ohsie, David wrote:
>
> > Andrew, my experience using firefox and chrome (and I think IE as well)
> to
> > access CAS protected applications differs.   If the cookies are set right
> by
> > the server, it is sufficient to kill the browser to force a new login.
> >
> >
> >
> > I'm not claiming that public internet terminals are safe or that there
> > are no ways to exploit this, but I would say that if your application
> > remains accessible after your browser is restarted, then you should be
> > looking at your application setup and then your CAS setup to ensure
> > that the cookies are set to expire upon the end of the session (and
> > that the caching control is also set properly for sensitive pages).
> > None of this is foolproof, but basic safeguards should be maintained.
> >
> >
> >
> > David Ohsie
> >
> > Software Architect
> >
> > EMC Corporation
> >
> >
> >
> >
> >
> > From: Andrew Petro [mailto:ape...@unicon.net]
> > Sent: Thursday, February 28, 2013 2:43 PM
> > To: cas-user@lists.jasig.org
> > Subject: Re: [cas-user] Public computer login and CAS
> >
> >
> >
> > I believe this is a well-known issue.
> >
> >
> >
> > Modern browsers take liberties with their interpretation of the
> > duration of session-scoped cookies, such that merely closing the web
> > browser is no longer sufficient.
> >
> >
> >
> > Users need to either explicitly log out of CAS to end their single
> > sign-on session and out of your application to end their session with
> > your application, or explicitly log out of their operating system
> > desktop session to prevent others from accessing it.  The latter is far
> preferable.
> >
> >
> >
> > You can try to make explicit logout from CAS have a side effect of
> > single logout callbacks to your application to also log the user out
> > of the application, but this doesn't address the root issue of there
> > being a window of time within which the end user has valid session
> > cookies that the browser did not clean up on browser close such that
> > re-opening the browser can resurrect them.
> >
> >
> >
> > Known shared browser installs can and should be configured to
> > implement a tighter understanding of what a session cookie's duration
> > ought to be.  To the extent that you're curating browser installs for,
> > say, known-shared computers in computer labs on a campus, those
> > browser installs should be so configured.  In

Re: [cas-user] Which is the appropriate implementation: CAS-Proxy or CAS-Rest

[Andrew Petro]

app-main.war's acting as a portal, making requests on behalf of the end
user directly to app1.war and app2.war, is a proxy CAS n-tier delegated
authentication use case.


On Wed, Mar 6, 2013 at 12:53 PM, W.Alphonse HAROUNY wrote:

> Hi,
>
> I have a main application (app-main.war) acting as a portal towards other
> applications (app1.war, app2.war, ..).
> All these applications were CASsified.
>
> - The user is triggering app-main.war thru REST calls.
>In this module, the CAS was integrated using the jasig
> AuthenticationFilter.
> - Then according to the user's request, a new REST request is sent by
> "app-main.war" towards the target service (app1.war, app2.war, ...) .
>
> My question is about which is the appropriate implementation to let the
> whole works :
> 1/ Is it by integrating "cas-server-integration-restlet" api into the
> target sevices  (app1.war, app2.war, ...) ?
> 2/ Or is it better to declare "app-main.war" as a CAS Proxy towards
> (app1.war, app2.war, ...)
> and let it access the services ?
> 3/ And why ?
>
> Thank you.
> Alf.
> --
> View this message in context: Which is the appropriate implementation:
> CAS-Proxy or 
> CAS-Rest
> Sent from the CAS Users mailing list 
> archiveat 
> Nabble.com.
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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] What is the purpose of the service ticket

[Andrew Petro]

If you presented the TGT to any entity other than the CAS server, that
entity could then use that TGT to access the CAS server in the name of the
user, obtaining STs as the user.  Thus any entity presented with the TGT
becomes a potential illicit proxy.

STs are very-short-lived application-specific one-time-use password
replacements.  Appropriately vending and redeeming them is post of the
point of a CAS server. :)


On Thu, Mar 7, 2013 at 9:42 AM, Modi Tamam  wrote:

> Hi,
> I'm trying to figure out the purpose of the service ticket.
> I mean, why wouldn't I validate the TGT against each service
> that I want to intercat with, what is the added value of the ST?
>
> --
> Best Regards
> Mordechai Tamam
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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] What is the purpose of the service ticket

[Andrew Petro]

Sure.  The non-browser client is adopting the role of browser in the CAS
protocol.  It touches the TGT.

Still, by using the TGT to obtain an ST, your "" doesn't get to
see the TGT, only a short-lived one-time-use ST.  This is better than the
service itself touching the TGT, which it could then use as an illicit
proxy.

All that said, I'd readily agree that CAS has less to offer non-browser
clients and that you might well consider other options. The non-browser
client is presumably a custom application that can do smarter, more
sophisticated things than can a web browser.  As in, participate in OAuth,
or validate credentials to pull down a certificate and use TLS to
authenticate to the services it accesses on the user's behalf, or...

Andrew


On Thu, Mar 7, 2013 at 10:28 AM, Modi Tamam  wrote:

> Understood.
> I'll describe my use cases.
> Some of my clients use browsers and some are not.means that the non-
> browser clients workflow will be as follow:
>
>1. Obtain a TGT
>2. Obtain a ST
>3. Validate the ST (https:?ticket=)
>4. Interact with 
>
> My question is, what is the added value (from a security point of view) of
> the ST? (I mean, the client is allready aware to the TGT)
>
>
> On Thu, Mar 7, 2013 at 5:01 PM, Andrew Petro  wrote:
>
>> If you presented the TGT to any entity other than the CAS server, that
>> entity could then use that TGT to access the CAS server in the name of the
>> user, obtaining STs as the user.  Thus any entity presented with the TGT
>> becomes a potential illicit proxy.
>>
>> STs are very-short-lived application-specific one-time-use password
>> replacements.  Appropriately vending and redeeming them is post of the
>> point of a CAS server. :)
>>
>>
>> On Thu, Mar 7, 2013 at 9:42 AM, Modi Tamam  wrote:
>>
>>> Hi,
>>> I'm trying to figure out the purpose of the service ticket.
>>> I mean, why wouldn't I validate the TGT against each service
>>> that I want to intercat with, what is the added value of the ST?
>>>
>>> --
>>> Best Regards
>>> Mordechai Tamam
>>>
>>> --
>>> You are currently subscribed to cas-user@lists.jasig.org as: 
>>> ape...@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: 
>> modi.ta...@gmail.com
>>
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/cas-user
>>
>>
>
>
> --
> Best Regards
> Mordechai Tamam
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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] Restricting access to SAMLValidate to whitelisted sites and applications

[Andrew Petro]

A try to clarify some issues raised in this thread generally, and then I
get down to some ideas for addressing Michael's requirements specifically:

Service tickets are bearer tokens authenticating the end user.  They do not
authenticate services, applications, or anyone else.  These bearer tokens
are borne by the end user and by the application the end user presents them
to attempting to log in to it.

When you configure CAS to release attributes in exchange for a service
ticket, then you are configuring CAS to release attributes in exchange for
a token that authenticates only the end user.

If the bearer of a bearer token is compromised by the Adversary, then the
Adversary gains access to the borne tokens and, because they are bearer
tokens, can make use of them with impunity.

So, here, if the user agent is hacked, the Adversary can lay hands on the
service tickets the user acquires (or capture the user's password and then
acquire any other service tickets he likes) and can take those service
tickets and validate them himself, harvesting all the user attributes they
yield.

This is not a security defect in CAS as such.  It's just the nature of the
security model, of the design.  Service tickers are bearer tokens.  They
have these characteristics.

CAS adopters should configure CAS to release only user attributes that they
are willing to release under this security model (or enhance CAS to change
the security model).  That is, only release attributes you're willing to
release to the end user's user agent, which, sure, like all things in life,
might be compromised.  Or the end user might have given up his password in
a phishing attack.  Or shared it with his significant other with whom he's
now had a nasty breakup.  You get the idea.  End user authentication is a
horribly messy thing, and service tickets are only obtained by end user
authentication, not by authentication of anything else.  Bearer tokens
authenticating the end user.

Proxy Granting Tickets have different security properties.  A service must
authenticate itself (via an https callback mechanism) to obtain a PGT, and
a PGT authenticates that service in the context of its participation in the
end user's single sign-on session.

So.  If you want to add authentication of the service doing the ticket
validation, that's a fine thing to add.  I see it as on this roadmap:

https://wiki.jasig.org/x/OwE_Aw

and it would simplify aspects of CAS.  The PGT callback would be
unnecessary, since the PGT could be included directly in the validation
response.  ClearPass would be unnecessary, since the password could be
included directly as an attribute in the validation response.

It's a fine improvement to make.  It amounts to making service tickets no
longer bearer tokens and instead tokens that only the intended relying
party can successfully validate.

So then there's the question of how to authenticate these services, these
relying parties.  Shared secret, with the shared secrets registered in the
service registry, feels like the Simplest Thing That Could Possibly Work.
 If I were coding a proof of concept of this, I'd start there.  TLS has
potential.

Shibboleth in principle can handle this by encrypting the SAML assertion
with the relying party's public key so that only the holder of the private
key, the relying party, can decrypt it.  If my initial use cases for
services needing to obtain attributes JIT that ought not to be released to
end users were narrow enough, I might start there, introducing a Shibboleth
IdP for use with my CAS server and preferring it as the feature-rich engine
for attribute marshalling, transformation, and JIT release via encryted
SAML assertions.  I should immediately temper the enthusiasm of the signed
SAML assertions idea, though, with the recognition that encrypting SAML
assertions is not widely adopted and my impression is it's not supported as
widely as would be desirable.  Still, it's a formal and rigorous way to
accomplish this.

I'd also say this: you could invent a new, ClearPass-like CAS server
endpoint, say

/cas/attributes

and require applications to present a proxy ticket to authenticate to that,
just as today they present a proxy ticket to authenticate to ClearPass.
 The implementation of that endpoint would need to know how to translate
from the authenticated proxy chain to the set of services you'd like to
release, but a naive implementation of treating the last identifier in the
proxy chain as a service identifier and doing the service registry lookup
might well be good enough.

This would get you to a security model where the token is authenticating
the relying party in the context of the end user's SSO session rather than
just the end user, without inventing any new shared secrets, TLS reliances,
or public key cryptography, and instead leveraging the n-tier
authentication feature already in CAS.

Hope this helps.

I do think it wil be worth getting to an updated CAS product, protocol that
does authenticate

Re: [cas-user] Restricting access to SAMLValidate to whitelisted sites and applications

[Andrew Petro]

David,

That's not a nitpick, that's an essential point, and I appreciate your
making it.  My bad.

> Nitpick alert:  Andrew, your suggested scheme(s) still leaves ST's as
bearer
tokens with time and audience restrictions (audience restriction =
restriction on who the token is intended for).  Anyone possessing the the ST
will still be able to authenticate without providing any other evidence of
identity, if they can do it in time and before the token has been "used up".
So it is still a bearer token.


On Wed, Mar 20, 2013 at 4:29 PM, Ohsie, David  wrote:

> >  I do think a security model where service tickets are not merely bearer
> tokens will be even better.
>
> Nitpick alert:  Andrew, your suggested scheme(s) still leaves ST's as
> bearer
> tokens with time and audience restrictions (audience restriction =
> restriction on who the token is intended for).  Anyone possessing the the
> ST
> will still be able to authenticate without providing any other evidence of
> identity, if they can do it in time and before the token has been "used
> up".
> So it is still a bearer token.
>
> What your scheme does do is to enable enforcement of the audience
> restriction (service parameter), so that only the indended audience can
> even
> validate the ticket.
>
> What could be done to make the ST and TGT not be a bearer tokens is as
> follows:
>
>   1) The client presents a client cert in the ssl/tls negotiation when
> authenticating to CAS and indicates that he wants a HoK (holder of key) ST.
>
>   2) CAS authenticates the user and records their public key along with the
> service attribute in the ticket registry with the ST and TGT.
>
>   3) The client presents his client cert in the ssl/tls negotiation when
> sending the ST to the relying party (CAS client).
>
>   4) The relying party (CAS Client), presents the clients public key as one
> of the parameters when calling serviceValidate/samlValidate.
>
>   5) CAS checks that the client's public key matches the one stored in the
> ST during ST validation.
>
>   6) If the client presents a TGT to CAS to request an ST, the same check
> can be done so that the TGT is also HoK.
>
> Basically this is just SAML-like HoK validation implemented in CAS.
> Obviously it depend on the client possessing and using a client cert.
>
> Now you could take a similar approach to enforcing the audience
> restriction:
>
>   1) When the client ask for an ST, he presents the public key in the SSL
> cert presented by the service.
>
>   2) CAS records this "service public key" in the ST.
>
>   3) When the service calls "serviceValidate", it must present a client
> cert
> corresponding to the "service public key".
>
> This method would run into problems if there is any kind of "SSL" proxying
> going (as happens with my company's outgoing proxy), or if the target
> service is running in a cluster where SSL/TLS termination happens at the
> node, since each node would be have different public/private key pair.
>
> These are all somewhat preliminary thoughts made up when pondering SAML HoK
> tokens and then adapted to your audience restriction enforcement use case.
> They could all be wrong...
>
> David Ohsie
> ASD Arch. and Advanced Dev.
> 410-929-2092
>
>
>
> From: Andrew Petro [mailto:ape...@unicon.net]
> Sent: Wednesday, March 20, 2013 11:32 AM
> To: cas-user@lists.jasig.org
> Subject: Re: [cas-user] Restricting access to SAMLValidate to whitelisted
> sites and applications
>
> A try to clarify some issues raised in this thread generally, and then I
> get
> down to some ideas for addressing Michael's requirements specifically:
>
> Service tickets are bearer tokens authenticating the end user.  They do not
> authenticate services, applications, or anyone else.  These bearer tokens
> are borne by the end user and by the application the end user presents them
> to attempting to log in to it.
>
> When you configure CAS to release attributes in exchange for a service
> ticket, then you are configuring CAS to release attributes in exchange for
> a
> token that authenticates only the end user.
>
> If the bearer of a bearer token is compromised by the Adversary, then the
> Adversary gains access to the borne tokens and, because they are bearer
> tokens, can make use of them with impunity.
>
> So, here, if the user agent is hacked, the Adversary can lay hands on the
> service tickets the user acquires (or capture the user's password and then
> acquire any other service tickets he likes) and can take those service
> tickets and validate them himself, harvesting all the user attributes they
> yield.
>
> Th

Re: [cas-user] Restricting access to SAMLValidate to whitelisted sites and applications

[Andrew Petro]

On closer review, I was also incorrect in my characterization of the extent
to which encrypting SAML assertions is adopted: encrypting assertions of
identity is turned on by default in the Shibboleth IdP and is well
supported in the Shibboleth SP, and because this is the default, it is
adopted.  It's encrypting of authentication requests, not identity
assertions, that is not widely adopted.

Which leads me to believe that, circling back to Michael's original
question, introducing a Shibboleth IdP and relying upon it as the solution
for identity assertions that can only be consumed by the intended audience,
and integrating the desired applications via the Shibboleth SP software, is
a promising architecture to meet Michael's requirements.

> Shibboleth in principle can handle this by encrypting the SAML assertion
with the relying party's public key so that only the holder of the private
key, the relying party, can decrypt it.  If my initial use cases for
services needing to obtain attributes JIT that ought not to be released to
end users were narrow enough, I might start there, introducing a Shibboleth
IdP for use with my CAS server and preferring it as the feature-rich engine
for attribute marshalling, transformation, and JIT release via encryted
SAML assertions.  I should immediately temper the enthusiasm of the signed
SAML assertions idea, though, with the recognition that encrypting SAML
assertions is not widely adopted and my impression is it's not supported as
widely as would be desirable.  Still, it's a formal and rigorous way to
accomplish this.


On Wed, Mar 20, 2013 at 11:32 AM, Andrew Petro  wrote:

> A try to clarify some issues raised in this thread generally, and then I
> get down to some ideas for addressing Michael's requirements specifically:
>
> Service tickets are bearer tokens authenticating the end user.  They do
> not authenticate services, applications, or anyone else.  These bearer
> tokens are borne by the end user and by the application the end user
> presents them to attempting to log in to it.
>
> When you configure CAS to release attributes in exchange for a service
> ticket, then you are configuring CAS to release attributes in exchange for
> a token that authenticates only the end user.
>
> If the bearer of a bearer token is compromised by the Adversary, then the
> Adversary gains access to the borne tokens and, because they are bearer
> tokens, can make use of them with impunity.
>
> So, here, if the user agent is hacked, the Adversary can lay hands on the
> service tickets the user acquires (or capture the user's password and then
> acquire any other service tickets he likes) and can take those service
> tickets and validate them himself, harvesting all the user attributes they
> yield.
>
> This is not a security defect in CAS as such.  It's just the nature of the
> security model, of the design.  Service tickers are bearer tokens.  They
> have these characteristics.
>
> CAS adopters should configure CAS to release only user attributes that
> they are willing to release under this security model (or enhance CAS to
> change the security model).  That is, only release attributes you're
> willing to release to the end user's user agent, which, sure, like all
> things in life, might be compromised.  Or the end user might have given up
> his password in a phishing attack.  Or shared it with his significant other
> with whom he's now had a nasty breakup.  You get the idea.  End user
> authentication is a horribly messy thing, and service tickets are only
> obtained by end user authentication, not by authentication of anything
> else.  Bearer tokens authenticating the end user.
>
> Proxy Granting Tickets have different security properties.  A service must
> authenticate itself (via an https callback mechanism) to obtain a PGT, and
> a PGT authenticates that service in the context of its participation in the
> end user's single sign-on session.
>
> So.  If you want to add authentication of the service doing the ticket
> validation, that's a fine thing to add.  I see it as on this roadmap:
>
> https://wiki.jasig.org/x/OwE_Aw
>
> and it would simplify aspects of CAS.  The PGT callback would be
> unnecessary, since the PGT could be included directly in the validation
> response.  ClearPass would be unnecessary, since the password could be
> included directly as an attribute in the validation response.
>
> It's a fine improvement to make.  It amounts to making service tickets no
> longer bearer tokens and instead tokens that only the intended relying
> party can successfully validate.
>
> So then there's the question of how to authenticate these services, these
> relying parties.  Shared secret, with the shared secrets registered 

[cas-user] Unicon webinar about CAS next week

[Andrew Petro]

CAS community,

Unicon will be offering a live webinar next week, on Wednesday March 27th,
at 11:30am Eastern, a periodic update on Unicon's participation in and
around the Apereo CAS project.

This is a public webinar; any and all are welcome to attend.

More information is available at:

http://www.unicon.net/blog/apetro/2013_q1_coop_sup_cas_update

Kind regards,

Andrew

-- 
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] Comparison of SSO solutions and some concepts confusion.

[Andrew Petro]

Frederico,

CAS is scalable.  Cf. Jérôme's very recent presentation documenting 11
million authentications per day, 600 requests per second, served by a three
node CAS installation using MemCache ticket registry, etc.

http://www.parleys.com/#play/5159944ae4b0ffdd7e058b69/chapter20/about

CAS is extensible.  That's the reason for the modularity, the many
interfaces.  One important way CAS can be extended is through its Spring
Web Flow usage for the login flow.  This presentation is dated, but the
concept remains applicable:

https://vimeo.com/11631079

CAS has adoption for high availability use cases today.  See for example
this presentation on high availability CAS at Lamar University in the face
of hurricanes:

https://wiki.jasig.org/x/zhIoAw

CAS server implementations are available for a variety of platforms,
including Ruby, PHP, and of course Java.  CAS client libraries are
available for Java, .NET, PHP, and other platforms.

CAS uses JSP and CSS and the look and feel is customized in the normal way
using commodity web development practices.

CAS speaks the CAS protocol for communication between the CAS server as IdP
and CASified services as relying parties.  CAS can also be made to speak a
modified CAS protocol conveying attributes and has growing support for
other protocols i.e. OAuth. Cf.
https://wiki.jasig.org/display/CASUM/Protocols

CAS has a pluggable AuthenticationHandler interface with implementations
for supporting a variety of means of authenticating credentials.  Primarily
username and password credentials, but also e.g. x509 certificates.  Cf.
https://wiki.jasig.org/display/CASUM/Authentication

As I understand it, the OAuth support in CAS 3.5 can be leveraged to
accomplish login to CAS using Facebook.  I feel more secure in that
understanding for Jerome's comment on this presentation:
http://www.slideshare.net/microcline/whats-new-in-cas-35

CAS offers a "remember me" feature.  Cf.
https://wiki.jasig.org/display/CASUM/Remember+Me

CAS offers an audit trail, gathers some statistics, is inspectable using
JMX, and Unicon has recently contributed a new take on eventing in
cas-addons that might help on this front as well.

CAS works for relying parties across domains and sub-domains.

CAS has documentation, primarily in the Jasig wiki.

Embedding login forms in services is in my humble opinion a worst practice
and avoids some of the advantages of centralized single sign-on, but people
have done this from time to time.

CAS has an active community.  Lists.  Conference presentations.  More
general blogs and integrations out in the world.

CAS supports Google integration both with Google accounts as a means to log
in to a CAS server and with a CAS server as a means to log in to a Google
for Domain account.

You can delegate to JAAS for credential validation if you really want to,
and likewise a CAS client library can expose JAAS abstractions if you
really want it to.  cf. https://wiki.jasig.org/display/CASUM/JAAS and
https://wiki.jasig.org/display/CASC/JAAS+Integration  .

> Andrew Petro says that he sees CAS as "a flexible and capable mechanism
for the Web authentication of local users." and Shibboleth as "the platform
for federating that local Web authentication and implementing formal
standards", ... . But I cannot connect this statements to the techical
facts.

Sorry to hear this continues to be confusing.  I thought this recorded
conference presentation was quite good, it may help:

https://wiki.jasig.org/x/AxMoAw

> Can I say that a "federated" scenario is SSO applied to sites in
different domains (or sub-domains)?
> Can I say that a "federated" scenario characterizes that the identity
provider should gather user informations in different organizations
(protected databases or directories)?
> Doesn't the CAS server support authentication across multiple domains or
sub-domains?

Yes, CAS supports CASified services across any domains and sub-domains you
like; no, that's not what's meant by "federation".

Federation ensues when you have multiple providers of identity and of
services from different organizations.   So, perhaps, some of your
customers operate their own Identity Providers and they might use those to
log in to services that your company provides.  Or, likewise, your company
might provide an Identity Provider whereby your employees could log in to
applications (Service Providers) operated by your clients.

Cf. InCommon.  In principle, users and identities from any of these 290
identity providers:

https://incommon.org/federation/info/all-entities.html#IdPs

could log in to any of these 1071 service providers:

https://incommon.org/federation/info/all-entities.html#SPs

(The technology allows this; a policy layer governs who accepts what
identities from what; discovery services attempt to make the experience of
all this sane.)

CAS is a great solution for implementing singl

Re: [cas-user] Suspicious login tracking

[Andrew Petro]

Mearl,

There is not yet anything in CAS that resembles Facebook's "suspicious
login tracking", but adding those sorts of risk-based behavior features is
a *fantastic* idea.

Andrew


On Fri, Apr 19, 2013 at 9:34 AM, Danner, Mearl  wrote:

> Is there anything in CAS that resembles Facebook's "suspicious login
> tracking"? Where if a login comes from an IP in an area far away from your
> normal login activity that it will give a warning, or ask for security
> questions?
>
> Thanks
>
> Mearl Danner
> Systems Programmer
> Samford University Technology Services
> http://www.samford.edu
>
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] phpCAS in an MVC Framework

[Andrew Petro]

Evan,

You might take a look at the Drupal CAS integration, which itself depends
upon and makes use of phpCAS, for an example of bridging phpCAS into a
framework's approach to user authentication.

Kind regards,

Andrew




On Wed, May 15, 2013 at 8:46 AM, Sheffield, Evan <
esheffi...@ivantagehealth.com> wrote:

> Hi all,
>
> I'm curious if anyone has any experience using phpCAS in the context of an
> MVC Framework. In particular, I've been using Zend Framework 2. The
> examples given in the phpCAS docs work well for requiring authentication
> for pages, but it would be nice to do things in broader strokes and force
> authentication at the module level or inside of controllers. I'd love to
> hear if anyone has any thoughts on this.
>
> --
> Evan Sheffield
> Programmer
>  iVantage Health Analytics®
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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] purpose of Username in services management

[Andrew Petro]

Adam,

See

http://www.unicon.net/blog/apetro/q3_2012_cas_progress

the section titled
"Per-service selection of attribute to use as username".

Yes, the username can also be released as a user attribute.  The CAS
protocol traditionally conveys a username, and this feature allows
selecting which attribute should be used as the username for that service.

Sorry to hear it's erroring out for you.  What service registry
implementation are you using, and what's the error?

Kind regards,

Andrew




On Tue, May 21, 2013 at 9:59 AM, Adam Causey  wrote:

> I noticed that the latest version of CAS that we installed has a
> 'Username' dropdown box on the services management page.  What is the
> purpose of this, and can't the username be given as part of the listed
> attributes?
>
> None of my services have this selected, and if I try to set the Username
> through the web interface, I get an error message.
>
> Thanks,
>
> Adam Causey
> Virginia Commonwealth University 
>
>  --
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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] Can anyone point me to SAML federation based on CAS.?

[Andrew Petro]

Belandran,

Not sure I understand your question.  CAS has no support for federations as
such.  See instead Shibboleth IdP.  CAS does have a wee bit of SAML
support, enough for adhoc SAML login to things like Google Apps, as Misagh
linked.

I'm not aware of any federations of CAS servers or usages of CAS to e.g.
participate in SAML federations like InCommon.  I'd  be very surprised to
learn of such a thing.

Kind regards,

Andrew



On Wed, May 22, 2013 at 8:09 PM, Balendran Thavarajah <
balendran.thavara...@standards.org.au> wrote:

> Hi All,
>
> ** **
>
> Can anyone point me to a federation implementation on CAS anywhere in the
> world for reference? Thanks for your help in advance.
>
> ** **
>
> Thanks
>
> ** **
>
> ** **
>
> ** **
>
> [image: Description: Description: Description: Description: Description:
> Description: Description: Standards Australia]**
>
> *Balendran Thavarajah* 
>
> Development Manager, Information Technology  |  Standards Australia
>
> Level 10, 20 Bridge Street Sydney NSW 2000 
>
> GPO Box 476 Sydney NSW 2001 
>
> P +61 2 9237 6094  |  M 040311  |  F +61 2 9237 6050  |
> www.standards.org.au 
>
> Follow us:
>
> [image: Description: Description: Description: Description: Description:
> Description: Description:
> http://www.standards.org.au/PublishingImages/Email2013twitter.gif]
> 
>
> [image: Description: Description: Description: Description: Description:
> Description: Description:
> http://www.standards.org.au/PublishingImages/Email2013linkedin.gif]
> 
>
> [image: Description: Description: Description: Description: Description:
> Description: Description:
> http://www.standards.org.au/PublishingImages/Email2013facebook.gif]
> 
>
> This email is confidential. If received in error, please delete it from
> your system.
>
> ** **
>
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> __
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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] Administratively invalidate TGT?

[Andrew Petro]

No, CAS doesn't ship with that feature, at least not surfaced in a handy
Web-based UI.

You might be able to instrument the ticket registry using JMX and edit it
live from a JMX console.

If your registry implementation is database-backed, you might be able to
edit the database live, though backdooring into data sources accessed via
JPA has some complexity to it.

This is a step in the direction of reporting on live sessions.  One could
imagine enhancing this modestly to provide a UI that exercises a REST call
to zap unwanted single sign-on sessions.
https://github.com/Unicon/cas-addons/wiki/Active-SSO-Sessions-Report

Sounds like a good feature idea to me.

Kind regards,

Andrew


On Wed, May 29, 2013 at 1:34 PM, Tom Poage  wrote:

> Hello,
>
> Is there a way in CAS to administratively invalidate/destroy a TGT(s) for
> a given principal?
>
> Thinking of a case with a compromised account and system policy of
> relatively long-lived TGTs (multiple hours).
>
> Thanks!
> Tom.
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] Administratively invalidate TGT?

[Andrew Petro]

Tom, yes, exactly.  An administrator may not have ready access to the TGT
identifier of the TGT to be terminated.

That is, the request:

"Terminate all SSO sessions active for user 'apetro'."  seems more
plausible than the request "Terminate TGT with identifier
TGT-656-2342342-cas1".

So offhand I think the current REST APIs aren't quite sufficient.  They
might well be the APIs that something else calls to effect the TGT
termination, but I think there's a need for something else to front it to
do the translation from the business need to the TGT termination command.

Andrew


On Wed, May 29, 2013 at 2:21 PM, Tom Poage  wrote:

> On May 29, 2013, at 11:05 AM, Marvin Addison 
> wrote:
> > It just occurs to me that strictly speaking we already have support for
> the latter. The RESTful API exposes the following method:
> >
> > public void destroyTicketGrantingTicket(final String
> ticketGrantingTicketId) {...}
>
> The REST API sounds promising, though for the case I had in mind, being
> able to identify and invalidate TGT(s) by principal name would be best.
> Optionally, perform 'logout' call backs to registered services.
>
> Given warnings on the corresponding web page, we might consider deploying
> an additional node in the CAS cluster, not exposed to the outside world
> (cf. load balancer), whose principal purpose would be to expose the API to
> security apps (kind of a waste of resources tho'). That, or protect the API
> paths using e.g. public key.
>
> Tom.
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] Security Implications for redirecting to HTTP site after authentication

[Andrew Petro]

Rich,

Only the normal concerns of exposure of secure application session cookies
to interception.

Cf. http://en.wikipedia.org/wiki/Firesheep

(If your application is worth logging into, it's probably worth accessing
via https: after login.)

Kind regards,

Andrew


On Fri, May 31, 2013 at 2:40 PM, Richard von Rauchhaupt <
richard.vonrauchha...@stonybrook.edu> wrote:

> Are there any security concerns for redirecting to an HTTP site after
> authenticating?
>
> Thanks,
> Rich
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] clearpass security question

[Andrew Petro]

Cheers,

Proxy tickets and proxy granting tickets are bearer credentials.  When you
grabbed the tickets, you became the bearer, and could then participate in
the CAS protocol in all ways as the intended bearer of those tokens.

CAS authenticates the identity of the proxying service on issuing a PGT, by
pushing the PGT to an https:// URL.  That https:// server-side SSL cert is
the proxying service's credential to obtain a PGT and that https:// URL is
revealed in the validation response for all proxy tickets obtained from
that PGT.

PGTs are also bearer credentials.  The proxying service uses its PGT to
obtain PTs.

The idea is that proxying services should protect their PGTs from hijacking
by not exposing them.  They should be protected from eavesdropping and man
in the middle attacks by their transport via https:// when CAS vends the
PGT and when the service redeems the PGT to obtain PTs.

But there's no magic here.  If the proxying service does something insecure
with that PGT bearer credential, like displaying it to users, then anyone
laying hands on that PGT can masquarade as the proxying service.

It might be an interesting enhancement for CAS to e.g. authenticate the
calling service on the /cas/proxy call, but that would just move the
service authentication a little closer to the vending of the PT, which
would still be a bearer token.

Making PTs not-bearer-tokens in the general case would be difficult in that
it's not clear how a CAS client library ought to authenticate the bearer of
a PT except that the bearer is bearing a PT.  Of course, there's nothing
preventing your proxy-ticket-accepting application from authenticating
requests in multiple ways in its specific case, i.e. it could restrict
based on apparent remote address, require a client-side SSL cert on the
request, *and* require a valid PT.  That's actually a kind of cute idea.
 If you would end up enhancing CAS client libraries to implement support
for that, would be a wonderful thing to share the resulting code.

Kind regards,

Andrew




On Tue, Jun 11, 2013 at 6:00 AM, n99  wrote:

> Hello
>
> I have configured clearpass to release credentials using proxy cas.
>
> I have configured the clearpass-configuration.xml to have one host in the
> "allowedProxyChains" bean for testing which is my own host.
>
> The clearpass Cas20ProxyReceivingTicketValidationFilter does the check to
> make sure the host that requested the Proxy Ticket obtained through
>
>
> https://cas-server.me.edu/cas/proxy?targetService=https://cas-server.me.edu/cas/clearPass&pgt=TGT-1-dfY33r3r3r3r3etc
>
> is the same as this host in "allowedProxyChains" or an
>
> "org.jasig.cas.client.validation.InvalidProxyChainTicketValidationException"
> is thrown.
>
> Is is all fine.
>
> However if I grab the proxyticket that is returned from
>
>
> https://cas-server.me.edu/cas/proxy?targetService=https://cas-server.me.edu/cas/clearPass&pgt=TGT-1-dfY33r3r3r3r3etc
> with the response
>
> 
> 
> ST-16-a...etc
> 
> 
>
> and use wget or such like from any other server clear pass validates the
> request and passes credentials to that machine.
>
> Should clearpass be also validating the request for the password also comes
> from the same machine that requested the Proxy Ticket?
>
> Or is it an impossible scenario that Proxy Tickets can be hijacked?
>
> Cheers
>
>
>
>
> --
> View this message in context:
> http://jasig.275507.n4.nabble.com/clearpass-security-question-tp4659834.html
> Sent from the CAS Users mailing list archive at Nabble.com.
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> ape...@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] Access Governing

[Andrew Petro]

See also

Webinar about experience implementing this feature at Fordham, from which
project the cas-addons code derives:

https://unicon.adobeconnect.com/_a989300636/p6lj8afl7h3/

Slideware from Jasig-Sakai conference at which solution presented:

https://wiki.jasig.org/x/ERIoAw

Enjoy.

Andrew




On Wed, Jun 12, 2013 at 3:25 PM, Dmitriy Kopylenko wrote:

> This facility has been implemented and released in cas-addons. Take a look
> to see if it would satisfy your needs:
> https://github.com/Unicon/cas-addons/wiki/Role-Based-Services-Authorization
>
> Best,
> Dmitriy.
>
> On Jun 12, 2013, at 3:21 PM, Marvin S. Addison 
> wrote:
>
> One of our needs is access
> governing, that is, CAS controls who can and who cannot SSO to any of
> our apps based on the users' role (faculty, staff and student) in the
> institution.
>
>
> CAS does not support centralized authorization policy. The model it
> supports out of the box is to release metadata about a user from the
> authentication system of record, and it is the responsibility of the
> relying part (CAS client) to enforce security policy based on that
> information. That said you could implement centralized access control by
> extending the ServiceRegistry component. Indeed, I believe such a system
> has been implemented by at least one member of the CAS community. (I recall
> Unicon did something of this sort for a school; maybe one of those folks
> can speak up with more info.)
>
> M
>
> --
> 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: ape...@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] Config JASIG CAS to work with SAML (Zendesk)

[Andrew Petro]

Winson,

A way to get really great SAML support for use with CAS is to use CAS to
log users in to a Shibboleth IdP and then use the Shibboleth IdP to do all
the SAML work.

Kind regards,

Andrew



On Thu, Jun 13, 2013 at 1:39 PM, Winson Huang wrote:

>  Hi,
>
> ** **
>
> We want to add Zendesk to out CAS SSO. We have already enabled SAML Single
> Sign On in Zendesk (
> https://support.zendesk.com/entries/514714-Using-SAML-for-single-sign-on-Plus-and-Enterprise-
> ).
>
> ** **
>
> When we tried to access Zendesk login page, it will redirect to SSO login
> page which is good. But when entering user name and password, it shows a
> blank page rather than redirecting back to Zendesk. 
>
> ** **
>
> We asked Zendesk support and the answer is because the assertion being
> sent from your SAML server isn't formatted correctly.
>
> ** **
>
> We want to know how to configure CAS to make it working.  
>
> ** **
>
> *Thanks! *
>
> * *
>
> *Winson*
>
> * *
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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] Multiple search base for LDAP

[Andrew Petro]

Supporting multiple search bases came up again in a Unicon technical
support context, so I've added a page to the CAS user manual documenting
the options, drawing on the inputs in this email list thread.

https://wiki.jasig.org/display/CASUM/LDAP+Authentication+with+Multiple+Search+Bases

Kind regards,

Andrew


On Wed, Jul 31, 2013 at 11:02 PM, Farzan Qureshi  wrote:

> Dear Community,
>
> I configured CAS an year ago. Our CAS authenticate users against our LDAP
> server. At the moment I have complete LDAP tree as a search option.
>
>p:filter="mail=%u"
>   p:searchBase="ou=people,dc=example,dc=com"
>   p:contextSource-ref="contextSource"
>   p:searchContextSource-ref="pooledContextSource" />
>
> If I want to have two search base that is one for Students and one for
> staff, how I can assign search base for two different user base?
>
> p:searchBase="ou=students,dc=example,dc=com"  ???
> p:searchBase="ou=staff,dc=example,dc=com" ???
>
> Thanks in anticipation.
>
> Kind regards,
>
>
> --
> *Farzan Qureshi* | Network Administrator & Help-desk Support | Rosmini
> College | (09) 487 0 530
>
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system manager (
> ad...@rosmini.school.nz). Please note that any views or opinions
> presented in this email are solely those of the author and do not
> necessarily represent those of the company. Finally, the recipient should
> check this email and any attachments for the presence of viruses. Rosmini
> College accepts no liability for any damage caused by any virus
> transmitted by this email.
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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] zero luck getting MySQL as services management backend

[Andrew Petro]

Aaron,

Depending where you're at with your proof-of-concept, maybe you'd like to
try the JSON-file-backed services registry instead?  I've found that not
having a runtime dependency on a database can save some trouble.

https://github.com/Unicon/cas-addons

https://github.com/Unicon/cas-addons/wiki/Configuring%20JSON%20Service%20Registry

Kind regards,

Andrew



On Tue, Sep 24, 2013 at 10:38 AM, Aaron Bennett  wrote:

>  Hi,
>
> ** **
>
> I have CAS 3.5.2 basically working (proof of concept wise) with AD
> Authentication, but I’m stymied getting the services management app to work
> with MySQL.  I’ve followed the instructions at:
>
> ** **
>
> https://wiki.jasig.org/display/CASUM/Configuring
>
> ** **
>
> But I keep getting this error:
>
> ** **
>
> Caused by: org.apache.commons.dbcp.SQLNestedException: Cannot create JDBC
> driver of class 'com.mysql.jdbc.Driver' for connect URL
> 'jdbc:mysql:://localhost/cas_services?autoReconnect=true'
>
> at
> org.apache.commons.dbcp.BasicDataSource.createConnectionFactory(BasicDataSource.java:1452)
> 
>
> at
> org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1371)
> 
>
> at
> org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
> 
>
> at
> org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider.getConnection(InjectedDataSourceConnectionProvider.java:71)
> 
>
> at
> org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:446)
> 
>
> ... 64 more
>
> Caused by: java.sql.SQLException: No suitable driver
>
> ** **
>
> ( see http://pastebin.com/vegVPaQ8 for the full cas.log )
>
> ** **
>
> Here’s what I’ve got in pom.xml – 
>
> ** **
>
> 
>
>
>
> commons-dbcp
>
> commons-dbcp
>
> 1.4
>
> runtime
>
> 
>
> 
>
> 
>
> org.hibernate
>
> hibernate-core
>
> compile
>
> 3.5.0-CR-2
>
> 
>
> 
>
> org.hibernate
>
> hibernate-entitymanager
>
> 3.5.0-CR-2
>
> 
>
> 
>
> 
>
> org.jasig.cas
>
> cas-server-support-jdbc
>
> ${cas.version}
>
> 
>
> 
>
> 
>
> mysql
>
> mysql-connector-java
>
> 5.1.26
>
> 
>
> 
>
> ** **
>
> And here’s the relevant snippets from deployerConfigContext.xml:
>
> ** **
>
>  class="org.jasig.cas.services.JpaServiceRegistryDaoImpl"
>
> p:entityManagerFactory-ref="entityManagerFactory" />
>
> 
>
>  class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
> 
>
> 
>
> 
>
>  class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
>
>   value="true"/>
>
>  *
> ***
>
> 
>
>
>
>
>
> 
>
>  key="hibernate.dialect">org.hibernate.dialect.MySQLDialect
>
>  key="hibernate.hbm2ddl.auto">update
>
> 
>
>
>
> 
>
> ** **
>
> ** **
>
>  class="org.springframework.orm.jpa.JpaTransactionManager">
>
>  ref="entityManagerFactory"/>
>
> 
>
> ** **
>
> **
> **
>
> ** **
>
> ** **
>
> 
> id="dataSource"
>
> class="org.apache.commons.dbcp.BasicDataSource"
>
> p:driverClassName="com.mysql.jdbc.Driver"
>
>
> p:url="jdbc:mysql:://localhost/cas_services?autoReconnect=true"
>
> p:password="snipped "
>
> p:username="user" />
>
> ** **
>
> I have verified that I can connect using that username and password with
> CLI mysql.
>
> ** **
>
> I have also placed mysql-connector-java-5.1.26-bin.jar in
> $TOMCAT_HOME/lib.  I’m using tomcat 7.0.42.
>
> ** **
>
> Thanks for your time,
>
> ** **
>
> Aaron Bennett
>
> ** **
>
> ** **
>
> ---
>
> Aaron Bennett
>
> Manager of Systems Administration
>
> Clark University ITS
>
> W:508.793.7315
>
> ** **
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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 uns

Re: [cas-user] CAS Client Security Vulnerability CVE-2014-4172

[Andrew Petro]

MA> we will consider providing official patches for [Java CAS Client 3.2
and 3.1] lines if there is interest.

TM> if [fixed versions of 3.2 and 3.1 Java CAS client versions] were
available that would ease the patching, I'm sure.

Yes, it would ease patching.  I'm finding getting a uPortal 4.0 release
squared away jumping from a Java CAS Client 3.2 version to 3.3.2 to be
substantially unpleasant.

Andrew



On Mon, Aug 11, 2014 at 4:50 PM, Tim McLaughlin 
wrote:

> On 2014/08/11, 12:46 PM, "Marvin Addison" 
> wrote:
>
> >> Does this affect ALL versions of the Java client prior to 3.3.2?
> >
> >I did code review of the latest 3.2 and 3.1 versions and they were
> >both vulnerable. I built one-off patches for my institution, but we
> >will consider providing official patches for those lines if there is
> >interest.
>
> So far I'm doing fact-finding before I announce to folks here, but if they
> were available that would ease the patching, I'm sure.  Don't know how
> much trouble that is.  :)
>
> For my couple of apps, I will probably take the opportunity to get current.
>
> >
> >> Also, is there a way to get the 3.3.2 jar without having to do a Maven
> >> build?  Latest on the downloads site is 3.2.x.
> >
> >I noticed there's no download bundle as well. I imagine Scott simply
> >hasn't gotten to it yet, but I'm sure simply mentioning it here will
> >make it magically appear :)
> >
> >M
>
> :) As always, the work of those of you officially involved with CAS is
> much appreciated.
>
> Thanks,
> Tim
>
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> apetro.li...@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: 
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 Client Security Vulnerability CVE-2014-4172

[Andrew Petro]

Okay.  So, a cas-client-core-3.2.1.1 that

1) Fixes cas-client-core , and
2) drops whatever integration modules cannot be built

?  And then many folks can bop to 3.2.1.1, ignore the missing integration
modules they aren't using anyway, and be happy.  And folks who are using
those modules can monkey patch only their cas-client-core .jar and be
somewhat happy. ?

Andrew



On Tue, Aug 12, 2014 at 8:02 AM, Marvin Addison 
wrote:

> > Yes, it would ease patching.  I'm finding getting a uPortal 4.0 release
> > squared away jumping from a Java CAS Client 3.2 version to 3.3.2 to be
> > substantially unpleasant.
>
> Ok. Here's the catch. Some of the integration modules,
> cas-client-integration-atlassian comes to mind, have dependencies in
> third-party repositories that are defunct. That makes a complete
> project build sufficiently difficult if not impossible that the return
> on investment is not justifiable. I would imagine that most folks need
> cas-client-core exclusively, and I would recommend we focus our
> efforts on patches for that module alone. Additionally, that's the
> only module affected by patching.
>
> M
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> apetro.li...@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: 
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 Client Security Vulnerability CVE-2014-4172

[Andrew Petro]

This set of transitive dependency exclusions *might* allow bumping from
Java CAS Client 3.2.1 to 3.3.2:

https://github.com/Jasig/uPortal/pull/404

I'm concerned about potentially losing Tomcat 6 support (needs testing?)
and about how fragile this solution may be.  Still feeling like a bump to a
Java CAS Client 3.2.1.1 would be a more conservative and appropriate move
for this late in the rel-4-0-patches uPortal maintenance branch.



On Mon, Aug 11, 2014 at 10:50 PM, Andrew Petro 
wrote:

> MA> we will consider providing official patches for [Java CAS Client 3.2
> and 3.1] lines if there is interest.
>
> TM> if [fixed versions of 3.2 and 3.1 Java CAS client versions] were
> available that would ease the patching, I'm sure.
>
> Yes, it would ease patching.  I'm finding getting a uPortal 4.0 release
> squared away jumping from a Java CAS Client 3.2 version to 3.3.2 to be
> substantially unpleasant.
>
> Andrew
>
>
>
> On Mon, Aug 11, 2014 at 4:50 PM, Tim McLaughlin 
> wrote:
>
>> On 2014/08/11, 12:46 PM, "Marvin Addison" 
>> wrote:
>>
>> >> Does this affect ALL versions of the Java client prior to 3.3.2?
>> >
>> >I did code review of the latest 3.2 and 3.1 versions and they were
>> >both vulnerable. I built one-off patches for my institution, but we
>> >will consider providing official patches for those lines if there is
>> >interest.
>>
>> So far I'm doing fact-finding before I announce to folks here, but if they
>> were available that would ease the patching, I'm sure.  Don't know how
>> much trouble that is.  :)
>>
>> For my couple of apps, I will probably take the opportunity to get
>> current.
>>
>> >
>> >> Also, is there a way to get the 3.3.2 jar without having to do a Maven
>> >> build?  Latest on the downloads site is 3.2.x.
>> >
>> >I noticed there's no download bundle as well. I imagine Scott simply
>> >hasn't gotten to it yet, but I'm sure simply mentioning it here will
>> >make it magically appear :)
>> >
>> >M
>>
>> :) As always, the work of those of you officially involved with CAS is
>> much appreciated.
>>
>> Thanks,
>> Tim
>>
>>

-- 
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 Client Security Vulnerability CVE-2014-4172

[Andrew Petro]

MA> we will consider providing official patches for [Java CAS Client 3.2
and 3.1] lines if there is interest.

I'm still interested in a patch fixing this issue for the Java CAS Client
3.2 line specifically, since that's the CAS client version used in uPortal
4.0 and 4.1.

However, I've also developed a no-dependencies just-add-a-Filter solution:

https://github.com/Jasig/cas-server-security-filter/pull/6

and intend to ship (a fork of) that Filter in uPortal 4.0.15 and 4.1.1 in
order to un-block the uPortal releases without having to bump those
releases to Java CAS Client 3.3 under duress.

https://github.com/Jasig/uPortal/pull/405

https://github.com/Jasig/uPortal/pull/406

(It might very well be appropriate to circle back and upgrade to the Java
CAS Client 3.3 more calmly for other reasons.  In fact, I expect to update
uPortal `master` (towards uPortal 4.2) to use the Java CAS Client 3.3
version. But this Filter allows that upgrade to not be required in order to
be safe from this vulnerability.)


On Mon, Aug 11, 2014 at 10:50 PM, Andrew Petro 
wrote:

> MA> we will consider providing official patches for [Java CAS Client 3.2
> and 3.1] lines if there is interest.
>
> TM> if [fixed versions of 3.2 and 3.1 Java CAS client versions] were
> available that would ease the patching, I'm sure.
>
> Yes, it would ease patching.  I'm finding getting a uPortal 4.0 release
> squared away jumping from a Java CAS Client 3.2 version to 3.3.2 to be
> substantially unpleasant.
>
> Andrew
>
>
>
> On Mon, Aug 11, 2014 at 4:50 PM, Tim McLaughlin 
> wrote:
>
>> On 2014/08/11, 12:46 PM, "Marvin Addison" 
>> wrote:
>>
>> >> Does this affect ALL versions of the Java client prior to 3.3.2?
>> >
>> >I did code review of the latest 3.2 and 3.1 versions and they were
>> >both vulnerable. I built one-off patches for my institution, but we
>> >will consider providing official patches for those lines if there is
>> >interest.
>>
>> So far I'm doing fact-finding before I announce to folks here, but if they
>> were available that would ease the patching, I'm sure.  Don't know how
>> much trouble that is.  :)
>>
>> For my couple of apps, I will probably take the opportunity to get
>> current.
>>
>> >
>> >> Also, is there a way to get the 3.3.2 jar without having to do a Maven
>> >> build?  Latest on the downloads site is 3.2.x.
>> >
>> >I noticed there's no download bundle as well. I imagine Scott simply
>> >hasn't gotten to it yet, but I'm sure simply mentioning it here will
>> >make it magically appear :)
>> >
>> >M
>>
>> :) As always, the work of those of you officially involved with CAS is
>> much appreciated.
>>
>> Thanks,
>> Tim
>>
>>
>> --
>> You are currently subscribed to cas-user@lists.jasig.org as:
>> apetro.li...@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: 
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 Client Security Vulnerability CVE-2014-4172

[Andrew Petro]

AP> developed a no-dependencies just-add-a-Filter solution

This Filter is now described in this blog post, with instructions for
patching-in-place existing old Java CAS client usages, and with a compiled
.class file ready to download and apply.

http://apetro.ghost.io/cve-2014-4172-workaround-filter/

This should be a viable workaround for all potentially affected Java CAS
client libraries, even the old Yale ones, even third party libraries, for
environments where upgrading to Java CAS Client 3.3.2 or better isn't the
best first move to block this vulnerability.

Happy patching,

Andrew


On Mon, Aug 18, 2014 at 3:32 PM, Andrew Petro 
wrote:

> MA> we will consider providing official patches for [Java CAS Client 3.2
> and 3.1] lines if there is interest.
>
> I'm still interested in a patch fixing this issue for the Java CAS Client
> 3.2 line specifically, since that's the CAS client version used in uPortal
> 4.0 and 4.1.
>
> However, I've also developed a no-dependencies just-add-a-Filter solution:
>
> https://github.com/Jasig/cas-server-security-filter/pull/6
>
> and intend to ship (a fork of) that Filter in uPortal 4.0.15 and 4.1.1 in
> order to un-block the uPortal releases without having to bump those
> releases to Java CAS Client 3.3 under duress.
>
> https://github.com/Jasig/uPortal/pull/405
>
> https://github.com/Jasig/uPortal/pull/406
>
> (It might very well be appropriate to circle back and upgrade to the Java
> CAS Client 3.3 more calmly for other reasons.  In fact, I expect to update
> uPortal `master` (towards uPortal 4.2) to use the Java CAS Client 3.3
> version. But this Filter allows that upgrade to not be required in order to
> be safe from this vulnerability.)
>
>
> On Mon, Aug 11, 2014 at 10:50 PM, Andrew Petro 
> wrote:
>
>> MA> we will consider providing official patches for [Java CAS Client 3.2
>> and 3.1] lines if there is interest.
>>
>> TM> if [fixed versions of 3.2 and 3.1 Java CAS client versions] were
>> available that would ease the patching, I'm sure.
>>
>> Yes, it would ease patching.  I'm finding getting a uPortal 4.0 release
>> squared away jumping from a Java CAS Client 3.2 version to 3.3.2 to be
>> substantially unpleasant.
>>
>> Andrew
>>
>>
>>
>> On Mon, Aug 11, 2014 at 4:50 PM, Tim McLaughlin 
>> wrote:
>>
>>> On 2014/08/11, 12:46 PM, "Marvin Addison" 
>>> wrote:
>>>
>>> >> Does this affect ALL versions of the Java client prior to 3.3.2?
>>> >
>>> >I did code review of the latest 3.2 and 3.1 versions and they were
>>> >both vulnerable. I built one-off patches for my institution, but we
>>> >will consider providing official patches for those lines if there is
>>> >interest.
>>>
>>> So far I'm doing fact-finding before I announce to folks here, but if
>>> they
>>> were available that would ease the patching, I'm sure.  Don't know how
>>> much trouble that is.  :)
>>>
>>> For my couple of apps, I will probably take the opportunity to get
>>> current.
>>>
>>> >
>>> >> Also, is there a way to get the 3.3.2 jar without having to do a Maven
>>> >> build?  Latest on the downloads site is 3.2.x.
>>> >
>>> >I noticed there's no download bundle as well. I imagine Scott simply
>>> >hasn't gotten to it yet, but I'm sure simply mentioning it here will
>>> >make it magically appear :)
>>> >
>>> >M
>>>
>>> :) As always, the work of those of you officially involved with CAS is
>>> much appreciated.
>>>
>>> Thanks,
>>> Tim
>>>
>>>
>>> --
>>> You are currently subscribed to cas-user@lists.jasig.org as:
>>> apetro.li...@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: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

[cas-user] Java CAS Client 3.2.2 ?

[Andrew Petro]

How is this considering going?  Plans?

 * A patched Java CAS Client 3.2 likely?
 * Deciding not to do that in favor of pushing folks to adopt Java CAS
Client 3.3 and slap the vulnerability blocking filter in the front of
existing implementations until able to adopt Java CAS Client 3.3?

MA> I built one-off patches [of Java CAS Client 3.2 and 3.1] for my
institution, but we will consider providing official patches for those
lines if there is interest.


On Mon, Aug 11, 2014 at 10:50 PM, Andrew Petro 
wrote:

> MA> we will consider providing official patches for [Java CAS Client 3.2
> and 3.1] lines if there is interest.
>
> TM> if [fixed versions of 3.2 and 3.1 Java CAS client versions] were
> available that would ease the patching, I'm sure.
>
> Yes, it would ease patching.  I'm finding getting a uPortal 4.0 release
> squared away jumping from a Java CAS Client 3.2 version to 3.3.2 to be
> substantially unpleasant.
>
> Andrew
>
>
>
> On Mon, Aug 11, 2014 at 4:50 PM, Tim McLaughlin 
> wrote:
>
>> On 2014/08/11, 12:46 PM, "Marvin Addison" 
>> wrote:
>>
>> >> Does this affect ALL versions of the Java client prior to 3.3.2?
>> >
>> >I did code review of the latest 3.2 and 3.1 versions and they were
>> >both vulnerable. I built one-off patches for my institution, but we
>> >will consider providing official patches for those lines if there is
>> >interest.
>>
>> So far I'm doing fact-finding before I announce to folks here, but if they
>> were available that would ease the patching, I'm sure.  Don't know how
>> much trouble that is.  :)
>>
>> For my couple of apps, I will probably take the opportunity to get
>> current.
>>
>> >
>> >> Also, is there a way to get the 3.3.2 jar without having to do a Maven
>> >> build?  Latest on the downloads site is 3.2.x.
>> >
>> >I noticed there's no download bundle as well. I imagine Scott simply
>> >hasn't gotten to it yet, but I'm sure simply mentioning it here will
>> >make it magically appear :)
>> >
>> >M
>>
>> :) As always, the work of those of you officially involved with CAS is
>> much appreciated.
>>
>> Thanks,
>> Tim
>>
>>
>> --
>> You are currently subscribed to cas-user@lists.jasig.org as:
>> apetro.li...@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: 
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 CAS Client 3.2.2 ?

[Andrew Petro]

Those changes sound fine to me and worth making to get a fixed Java CAS
Client 3.2.2 out the door.

Andrew


On Mon, Sep 1, 2014 at 10:32 PM, Scott Battaglia 
wrote:

> If I make the following changes I can get a 3.2.2 build:
>
> 1. Ignore Saml11TicketValidatorTests (its running into some issue with the
> way it starts the server; apparently we ignore these on master which is
> weird)
> 2. Update Spy Memcache Client to latest version (only more recent versions
> are in Maven Central)
> 3. Update Atlassian repository to new location
>
> I am assuming no one has any issue with these changes to get a 3.2.2 build
> out.  If not, I'll cut the release tomorrow night.
>
>
>
>
>

-- 
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] ldap-pwd-expiration module

[Andrew Petro]

> Is there any interest in implementing the functionality of this 
module into the main sources?


Yes.  Very much so.  For some reasonable meaning of "into the main 
sources".


I could see it as a an extension as productized and easy to implement as 
ClearPass.  I could also see it as a core CAS module alongside the other 
core included CAS modules, perhaps even with these password policy 
checks in the CAS login web flow by default but doing nothing in the 
case where no implementation of the password policy API is available, 
assuming buy-in of CAS committers on the value of the feature versus its 
complexity cost.  I'll start a thread on cas-dev on this topic.


Your changes all sound welcome improvements.  Can you share the source?  
I'd love to merge your improvements in as the basis of a more 
productized update to this module, whether the next answer here is 
polishing an extension module ala ClearPass or inlining the 
functionality into CAS.


Thanks,

Andrew



On 01/25/2011 05:02 AM, Felix Schumacher wrote:

Hi,

we have use ldap-pwd-expiration module as a starting point to 
implement warnings and a short webflow to change passwords if the user 
has a password, which is short of expiring.


There were a few things, which we did differently than shown in the wiki.

1. We started with placing the module inside the checked out svn 
sources and edited the pom.xml directly to include it.
   While that seemed to work - it created a jar file with the classes 
inside - the war file of our overlay build hat a few problems.

   a) The needed "principal" could not be found by the webflow, since
   b) ldap-pwd-expiration changed a few central classes while 
remaining the old classnames.
   Those two things were a result of ordering of the jar-files in 
WEB-INF/lib/. Tomcat will use the first class for a given name, that 
it finds in the classloader. (We could have solved it by renaming 
ldap-pwd-expiration jar to start with aa- or something like that. But 
that seems a bit flakey.


2. We changed the webflow of ldap-pwd-expiration as suggested by 
another thread on this list, to leave out the "viewScope" out of the 
new end-states.


3. We changed the code, which parses the ldap exception messages, so 
it can be configured by spring. We don't use ads and our ldap server 
has different error messages.


4. As a result we copied all files from the ldap-pwd-expiration module 
into our overlay directory and changed the names of the classes, to 
avoid classloader problems.


5. (There is a minor bug in the original source. It will overwrite the 
instance variable validDays with user specific values)



Is there any interest in implementing the functionality of this module 
into the main sources?


Any thoughts?
 Felix






--
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 and ADFS integration

[Andrew Petro]

> In short, merging SSO domains is difficult to impossible.

While difficult, I expect the merge is feasible if you're open to 
somewhat complex solutions.


ADFS can operate as a SAML Relying Party / Service Provider.  There's a 
pretty good whitepaper on how to do this with Shibboleth.  (Disclaimer: 
I haven't actually personally done this configuration of ADFS.  In fact, 
I've never touched ADFS.)


http://technet.microsoft.com/en-us/library/gg317734(WS.10).aspx

As Marvin notes, you can front Shibboleth with CAS so that it's the 
implementation of the user experience for authentication.


So, you can achieve CAS SSO across ADFS-using applications by 
configuring ADFS to rely upon Shibboleth for SAML-based user 
authentication and then configuring Shibboleth to rely upon CAS to 
implement the user experience of user authentication.


It's a bit, um, involved, but it should work, with the user logging in 
to CAS once, and then experiencing SSO each time the request traverses 
the stack. This approach may be attractive to folks getting value out of 
CAS in other ways.


Andrew



On 01/26/2011 10:35 AM, Marvin Addison wrote:

We are now looking into integrating the system with ADFS (Active Directory 
Federation Services).

I'm not terribly familiar with ADFS, but it's my understanding it's
Microsoft's proprietary answer to Shibboleth and federated identity
management.  Assuming that's correct, this will be a difficult
integration if you want to avoid logging in again as you stated.  The
integration path with Shibboleth, in the simplest case, puts CAS in
front of Shib by making CAS the authentication provider for Shib; see
https://wiki.jasig.org/display/CASUM/Shibboleth-CAS+Integration for
more information.I can imagine that if ADFS exposes a Web/Web
service API, you could do similar, but it won't fulfill the
requirement to avoid reauthentication.  In short, merging SSO domains
is difficult to impossible.

M




--
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 and ADFS integration

[Andrew Petro]

Agreed.

Whether the "single" part of SSO is achieved depends on whether the 
authentication to the portal via ADFS incurs a SAML round trip and 
thereby requires authentication via Shibboleth, which would then be 
CASified.


If you've set up ADFS such that using ADFS to authenticate to the portal 
itself entails logging into ADFS via SAML and, in the proposed 
configuration, therefore a CAS login, then you'll get single sign on 
from that point on when you access another CASified application.  (Or 
Shibbolized application, or ADFS-ified application).


If the ADFS authentication to the portal does not entail 
SAML-authenticating to ADFS, then I agree the requirement of a user 
experience of single sign on won't be met.


To the extent that ADFS and the partner's portal isn't under your 
control, Shibbolizing it is going to be a non-starter.


Andrew


On 01/26/2011 03:16 PM, Marvin Addison wrote:

It's a bit, um, involved, but it should work, with the user logging in to
CAS once, and then experiencing SSO each time the request traverses the
stack.

The integration path Andrew sketched out doesn't meet the following
requirement as I understood it:

"Note that simply using LDAP for authenticating against Active
Directory is not a good enough solution for us, since it will require
the users to login again, instead of relying on their login to our
partner's portal."

I read the above as the user authenticates to an ADFS-secured portal
and it's desirable to leverage that authentication to transparently
authenticate to CAS.  I'm not aware of any solution that would meet
that requirement.

The solution Andrew outlined does provide an integration path, but it
requires an additional login to CAS for the workflow above.  If you
could force all users through CAS from the start, then you could
achieve true single sign-on, but I imagine that may not be possible.

M




--
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] Critical Security Vulnerability Notification CVE-2010-4476

[Andrew Petro]

CAS Adopters,

Be advised that most CAS deployments are vulnerable to the widely 
publicized not-a-defect-in-CAS-itself JVM defect CVE-2010-4476.  You 
should take immediate action to mitigate this vulnerability in your 
production environments.


Notification posted to website:

http://www.jasig.org/cas/news/cve-2010-4476

(This is the same issue as described in the recent "Important! Critical 
bug in all Java versions" thread.  Posting as a new thread to draw 
attention to the issue and to the Jasig CAS product response.)


Thanks are due to Robert Oschwald who raised that thread, to Marvin 
Addison for testing, and to the CAS Steering Committee for coordinating 
composing and posting a CAS-as-product response to this issue.


Feedback welcome on the website news entry, which doubtless can be 
improved, but I  hope it will help to get the word out to encourage 
mitigation of this serious issue.


Best wishes,

Andrew

Andrew Petro
Jasig CAS Steering Committee

Software Developer, Unicon, Inc.

--
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] Important! Critical bug in all Java versions

[Andrew Petro]

As noted in a new thread, CAS steering committee is responding to this 
serious issue with this notification post:


http://www.jasig.org/cas/news/cve-2010-4476

Best wishes,

Andrew


On 02/09/2011 09:29 AM, Marti, Robert wrote:

Correction... throwing 60 of those curls at my one server (rhel5 64bit, 4gb of 
ram, no java tuning) causes it to crawl.  It should be pretty easy to drop 
these at the load balancer/firewall tho, so at least we have a workaround.

Rob Marti


-Original Message-
From: Marti, Robert [mailto:rjm...@shsu.edu]
Sent: Wednesday, February 09, 2011 8:12 AM
To: cas-user@lists.jasig.org
Subject: RE: [cas-user] Important! Critical bug in all Java versions

->  curl -vH "Accept-Language: en-us;q=2.2250738585072012e-308"
->  http://lnxauth02d.shsu.edu:8080/sghe-cas/login
* About to connect() to lnxauth02d.shsu.edu port 8080
*   Trying 158.135.5.21... connected
* Connected to lnxauth02d.shsu.edu (158.135.5.21) port 8080

GET /sghe-cas/login HTTP/1.1
User-Agent: curl/7.15.5 (i386-redhat-linux-gnu) libcurl/7.15.5
OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: lnxauth02d.shsu.edu:8080
Accept: */*
Accept-Language: en-us;q=2.2250738585072012e-308


It just hangs that curl until I ctrl-C - the JVM still works fine (I can log in 
to the
box without any problems) using 1.6.0_22.

Rob Marti


-Original Message-
From: Robert Oschwald [mailto:robertoschw...@googlemail.com]
Sent: Wednesday, February 09, 2011 7:45 AM
To: cas-user@lists.jasig.org
Cc: cas-...@lists.jasig.org
Subject: [cas-user] Important! Critical bug in all Java versions

This is off topic but important to all CAS users.

There exists a remotely exploitable critical bug in Java which can
lead to a complete crash of the JVM.
Every admin is urged to immediately patch all Sun/Bea/Oracle Java
Versions on their servers.

Main cause of the problem is a flaw in the AMD/Intel floating point unit.

JVM Patcher:
https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-
Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=fpupdater-oth-
JPR@CDS-CDS_Developer


As noted above, every script kiddie can crash your remotely available
java app by simply sending the magic string in the HTTP-HEADER (e.g.
by using curl).


Hope it helps.

Robert
--
You are currently subscribed to cas-user@lists.jasig.org as:
r...@shsu.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: r...@shsu.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] CAS on the Cloud Service

[Andrew Petro]

Matt,

I noticed this email and have forwarded it to cas-steer for discussion 
of what the CAS Steering Committee would consider. :)


Without that discussion having happened, I'm not prepared to speak 
authoritatively to what additional strategic effort, coordination, 
calories the CAS Steering Committee might be willing to consider applying.


I will however note that in some ways this is less a question of whom 
Jasig and cas-steer would consider working with, and more a matter of 
who would consider working with the CAS community.  CAS is free and open 
source software with a simple, well-documented protocol, an extensible 
modular implementation, and most importantly, a community of developers 
and participants with a justly-earned reputation for friendliness. When 
providers of SSO-as-a-service apply effort and engage with the CAS 
community to enhance the CAS support of their products and services, I'd 
expect they'd get supportive responses on the lists and elsewhere as 
most other comers have, and I'd expect they could be quite successful in 
CAS-integrating their products.


I appreciate that's not quite what you asked, though.  Your question 
seems to go more to the strategic value to Jasig and to CAS in 
instigating this kind of support for the CAS protocol in these products 
and services.  It's a worthwhile strategic question, one I'll take up 
with the CAS Steering Committee, which doesn't preclude further 
discussion here as well.


Thanks for bringing it up.

Andrew



On 03/29/2011 08:22 AM, Smith, Matthew J. wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Would JASIG or the CAS Steering Committee (or whomever is appropriate)
consider working with an existing authentication provider like
http://www.protectnetwork.org/ to offer the CAS protocol as an
additional authentication service?  ProtectNetwork today advertises
"Open standards compliant: Shibboleth, SAML, OpenID", so they are
already multi-protocol.

- -Matt

On 03/28/2011 03:55 PM, Marvin Addison wrote:

I was thinking if we can start CAS on Cloud then it would very
easier for any developer to test and learn CAS.

Sounds great except "cloud" is far too vague in terms of both
provisioning and consumption. Practically speaking, who would
host this offering?

What features should this cloud offering provide? (I assume the
cloud offering is strictly for demonstration and evaluation). The
most common features needed by deployers:

- Username/password authentication with LDAP backend -
JpaTicketRegistry for ticket storage/registered services
(Memcached comes in second by my very unofficial scorekeeping)

Anything else?

M



- -- 
Matthew J. Smith

University of Connecticut UITS
matt.sm...@uconn.edu
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2RzyIACgkQGER0Au6g8xBUiACg5WVE+P09Cy25jPi5gIct2kW9
1q0AoLKHCMaMprn2QWtKudbfP9zkDFoJ
=Ou5b
-END PGP SIGNATURE-





--
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] April Community call reminder

[Andrew Petro]

Reminder: April 2011 community call happening shortly (< 10 minutes)

Scott Holodak will be presenting an overview of the .NET CAS Client
Andrew Petro and Scott Battaglia will be recapping the NYC CAS Meetup

Wiki: https://wiki.jasig.org/display/CAS/2011-04-13+Community+Call

Audio: http://bit.ly/fjhAcj

Slides and screensharing: 
http://connectpro31884307.adobeconnect.com/april-2011-cas-community-call/


Hope to see you there.

Andrew



--
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] Spotlight on Open Source

[Andrew Petro]

I'll be there.

On 05/04/2011 01:59 PM, Biondi, Dan wrote:

As will I.  There are currently around 95 folks registered.

-Dan

-Original Message-
From: William G. Thompson, Jr. [mailto:wgt...@gmail.com]
Sent: Tuesday, May 03, 2011 6:04 PM
To: cas-user@lists.jasig.org
Subject: Re: [cas-user] Spotlight on Open Source

I'll be there as well.  Looking forward to meeting you and catching with the 
crew.

Best,
Bill



On Tue, May 3, 2011 at 8:49 PM, Marvin Addison  wrote:

I'll be there.  I know several faces, but I lean on the name tags
pretty heavily.  See you there!

M

--
You are currently subscribed to cas-user@lists.jasig.org as:
wgt...@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: 
bion...@skymail.csus.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] Casifying applications through Uportal

[Andrew Petro]

One cheap trick to consider here is iframing a URL for logging in to the 
framed application via CAS rather than a URL for the application itself.


That is, rather than putting

https://www.ensai.fr/webapp

in an inline frame, instead put

https://cas.ensai.fr/login?service=https://www.ensai.fr/webapp

in that frame (where the value of the service parameter is whatever URL 
at which the application expects to receive service tickets).


Since the user is already logged in to CAS, CAS will redirect to the 
webapp with a viable service ticket, and the logged in application 
experience will appear in that inline frame.



One problem with this cheap trick is that in many applications, hitting 
it with a service ticket clobbers the existing session, which may be 
undesirable or unacceptable.


So the more sophisticated thing to do is to point the iframe at a URL 
with the behavior of redirecting to CAS if login is needed.  This is 
achievable with all CAS client libraries.


(Obligatory curmudgeonliness: inline frames are probably a bad idea and 
probably shouldn't be used in your portal.)



Portlets != inline frames.  You can put an inline frame in uPortal -- 
you could also put a portlet in uPortal.  And portlets can generate 
inline frames.  (I think there's some way in which the spec says they 
shouldn't, but in practice they can and sometimes do.)  uPortal includes 
rather elegant support for portlets obtaining proxy tickets and using 
CAS's n-tier delegated authentication capabilities, so if you wanted to 
build real portlets rather than use inline frames there's certainly 
technology to support that.


Hope this helps,

Andrew



On 04/06/2011 05:27 AM, jabzouw wrote:

Hi all,

I will probably sound like stupid but i'm new using SSO-CAS with uportal. I 
succeeded installing a uPortal Version (French one Esup)and an external CAS 
server to authentify via a LDAP. Everything is great except that i intend to 
put some existing web applications in frames in the uportal. For instance, we 
have a wiki which uses the same LDAP than the cas. I would like to put this 
wiki in a frame in the uPortal and automtically be identified considering the 
fact i'm already authentified in the uPortal. I've read something about 
casifying media wiki with phpCas but i don't get the mechanism (not 
configuration files) but the logic in it. I've also read that with a small code 
in the instance of the portlet it would authentify what's in it (a frame is a 
portlet right ?).

Anyway i'm really lost and i could use some help there !

Again i'm sorry for languages mistakes i'm giving my best here.

Thanks a lot.

Best regards



--
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] Problem with CAS and commons upload

[Andrew Petro]

Thanks for raising this issue.

Please create a JIRA documenting the defect.

Is it convenient for you to produce a minimal noise example 
demonstrating this problem?  I'm thinking source that builds to a .war 
that includes the file upload servlet, declares the CAS filter, and maps 
the servlet behind and not behind the filter.


Not looking to create a bunch of work for you, but if you're in a 
position to provide such an example (would be a fine addition to the 
JIRA), Marvin and I are here at Jasig Dev Days through Friday and I know 
for me that jump start to seeing the problem you're seeing would 
appreciated.


Thanks,

Andrew



On 05/25/2011 04:25 PM, Garey Mills wrote:


I have a webapp that uses CAS. In the part of my app that I want 
filtered by CAS I have a file upload servlet.
When the HttpServletRequest arrives at the servlet the content type is 
null and there are no parameters. If I move
the file upload outside of the CAS-filtered area, the 
HttpServletRequest contains the proper content type and

parameters.

I am using CAS client 3.2.0.

Garey Mills
Library Systems Office
UC Berkeley




--
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] Casifying Microsoft Live@edu

[Andrew Petro]

Was this from MS somewhere publicly than can be documented in the CAS 
project wiki, or is this a one-off interaction every time to get these 
artifacts from the MS account manager?


On 06/03/2011 11:58 AM, Malarvizhi Perumalraja wrote:

Thank you Paul. We were able to get the sample code, documentation and SSO 
certificates from MS. Hopefully I can soon Casify Live@edu.

Thanks,
Malar

-Original Message-
From: Vitty, Paul [mailto:p.vi...@ulster.ac.uk]
Sent: Thursday, June 02, 2011 3:54 PM
To: cas-user@lists.jasig.org
Subject: Re: [cas-user] Casifying Microsoft Live@edu

Hi Malar,

I honestly can't remember where we found the documentation. If you have an MS 
account manager they should be able to point you to where their sample code and 
documentation is now located.

...

--
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] Spring Web Flow conversation lock acquisition timeout stops cas & tomcat from accepting new connections

[Andrew Petro]

Did this thread lead to finding anything to correct?

Andrew


On 2/15/2011 11:45 AM, Cary, Kim wrote:

Here's the reference:

http://forum.springsource.org/showthread.php?t=56618

I'm not committed to this as the root cause, but would sure like to find 
something I can correct.

On Feb 15, 2011, at 6:03 AM, Marvin Addison wrote:


Google doesn't have much on this, but one case shows some involvement with c3po 
failing to talk to the database.

That sounds pretty fantastic -- can you cite the links you found that
connected c3p0 with Webflow conversation behavior?  I'll try to do
some research today to see if I can find out anything further.

M

--





Our CAS service came up unresponsive (connection timed out) after throwing 
about 6 of these errors tonite.

Google doesn't have much on this, but one case shows some involvement with c3po 
failing to talk to the database. We use inspektr and our audit database hit a 
10Gb threshold tonite. Restarting tomcat without making any other changes put 
the service back into operation.

Can anyone share any clues on pursuing the root cause of the outage?

Thanks,
KC

Feb 13, 2011 7:12:03 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet cas threw exception
org.springframework.webflow.conversation.impl.LockTimeoutException: Unable to 
acquire conversation lock after 30 seconds
at 
org.springframework.webflow.conversation.impl.JdkConcurrentConversationLock.lock(JdkConcurrentConversationLock.java:44)
at 
org.springframework.webflow.conversation.impl.ContainedConversation.lock(ContainedConversation.java:69)
at 
org.springframework.webflow.execution.repository.support.ConversationBackedFlowExecutionLock.lock(ConversationBackedFlowExecutionLock.java:51)
at 
org.springframework.webflow.executor.FlowExecutorImpl.resumeExecution(FlowExecutorImpl.java:160)
at 
org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.handle(FlowHandlerAdapter.java:183)
at 
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:771)
at 
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:716)
at 
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:647)
at 
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:563)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at 
org.jasig.cas.web.init.SafeDispatcherServlet.service_aroundBody2(SafeDispatcherServlet.java:115)
at 
org.jasig.cas.web.init.SafeDispatcherServlet.service_aroundBody3$advice(SafeDispatcherServlet.java:44)
at 
org.jasig.cas.web.init.SafeDispatcherServlet.service(SafeDispatcherServlet.java:1)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
com.github.inspektr.common.web.ClientInfoThreadLocalFilter.doFilter(ClientInfoThreadLocalFilter.java:46)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:568)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:613)
Feb 13, 2011 7:12:14 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet cas threw exception
org.springframework.webflow.conversation.impl.LockTimeoutException: Unable to 
acquire conversation lock after 30 seconds
at 
org.springframework.webflow.conversation.impl.JdkConcurrentConversationLock.lock(JdkConcurrentConversationLock.java:44)
at 
org.springframework.webflow.conversation.impl.ContainedConversation.lock(ContainedConversation.java:69)
at 
org.springframework.webflow.execution.repository.support.ConversationBackedFlowExecutionLock.lock(Conver

Re: [cas-user] Single user store or multiple authenticationHandlers

[Andrew Petro]

Howard,

CAS server will happily support as many AuthenticationHandlers as you'd 
like to map.  CAS is not seeking to be your store of users and has no 
opinion about where you ought to store your users in how many stores.  
However, if you have more than on AuthenticationHandler, it's up to you 
to deal with potential username namespace collision -- i.e. if the user 
"hhill" exists in multiple user stores backing multiple mapped 
AuthenticationHandlers, there's no magic for differentiating these -- 
CAS is going to happily authenticate username "hhill" via either handler 
and will not disambiguate these on the ticket validation responses it 
provides to client applications.

The CAS client libraries aren't particularly designed to play nicely 
with others, i.e. CAS envisions itself as the one, simple way that users 
log in to applications that make use of CAS.  There's nothing 
particularly stopping you from supporting multiple ways to log in of 
which CAS is just one.  Some applications do this, e.g. uPortal supports 
both local username and password authentication and CAS authentication.  
But the CAS client libraries aren't going out of their way to enable 
this use case and in particular are not the mechanism for implementing 
login via multiple methods of which CAS is just one of several.

Best wishes,

Andrew


On 6/15/2011 4:06 PM, Howard wrote:
> Question on CAS client integration with Jasper. I have it working but 
> does this mean if I am able to login to the application  with a 
> authenticationHandlers it does not work for Jasper .
>
> Is the principal of CAS that there must be one single backend user 
> store or I should have multiple authenticationHandlers if I am to 
> login to Jasper not via a ticket .
>
> Any suggestions would be greatly welcomed
>
>
> Sent from my iPhone
> -- 
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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] Multi-tenant web app and cas

[Andrew Petro]

Dave,

You really need proxy callback URLs; that is, your polynymous 
application needs to authenticate on behalf of the user to other 
services using proxy CAS tickets?

Still a problem if you don't, but less problem to solve if only dealing 
with supporting the multiple service URLs and not multiple 
proxyCallbackUrls.

How many brands are we talking about here?  Six? Six hundred?  Is it 
feasible to give *the login portion of* each brand its own path such 
that you could declare and map N instances of the Spring Security 
filters, one for each brand and therefore serverName ?

Use a custom Filter to compute the request-based URLs and shove them 
into ThreadLocal such that your custom extension can read them from 
ThreadLocal where it needs them, since it doesn't have easy direct 
access to the ServletRequest?

However, allowing the client to assert the serverName is theoretically 
dangerous and invites illicit delegated authentication to your 
application, cf. https://wiki.jasig.org/display/CASC/CASFilter .

Best wishes,

Andrew


On 6/15/2011 3:52 PM, Dave Goodin wrote:
> We have a grails web application that has multiple url's mapped to it 
> in order to provide client branding.
> Were are using Spring Security Cas plugin to provide security.  It in 
> turn has a dependency on the 
> com.springsource.org.jasig.cas.client:3.1.8 jar and uses the 
> Cas20ServiceTicketValidator.  The ticket validator has a property 
> called proxyCallbackUrl that I want to be dynamic but currently it is 
> not.
>
> For example, client A accesses the site by https://www.clientA.com 
>  and client B accesses the site by 
> https://www.clientB.com .  I have configured 
> the CAS server service url's to correspond to these url's.
>
> My question is how can I configure a web app that services multiple 
> url's and the cas server to meet this need.  I have been thinking that 
> maybe I could override the Cas20ServiceTicketValidator but haven't 
> been able to find a way to grab the URL a client is coming in on 
> because I don't have access to the HTTP request.
> I have also been trying to think of a way to make the application 
> (regardless of the client URL) seem like a single application to the 
> CAS server.  The downfall of our current design with this last idea is 
> that all of the branding logic we have implemented is based on the 
> client's url (and the client URL is a mandate by our business).
>
> Any guidance would be greatly appreciated.
> -- 
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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

[cas-user] Test cas-user post from Google Group mirror - creating a new thread

[Andrew Petro]

My apologies for the noise on cas-user -- this is a test post from the 
new-ish Google Group mirror for this list, an experiment in increasing the 
ease of query and short-term-relationship access to this list, in followup 
to this lovely IRC conversation:

https://wiki.jasig.org/display/CAS/jasig-cas+IRC+Logs-2011-05-13

Andrew


-- 
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] Multi-factor authentication

[Andrew Petro]

Peishu,

There's nothing stopping you from implementing multifactor authentication.  
The login flow is extensible and in particular can be extended to involve 
multiple authentication steps with multiple factors.

At least one adopter cleverly implements multiple informal levels of 
assurance by chained CAS servers, with the higher assurance CAS server 
requiring login first via the lower assurance server (thereby achieving 
multiple factors and selection of level of assurance in relying applications 
simply by configuration of what CAS server URL to use).

https://wiki.jasig.org/display/CASUM/Second-Level+CAS+Server

All that said, no, CAS doesn't particularly support multi-factor 
authentication, in any version.

Would be a fine set of features to work on.  It's loosely on the roadmap and 
vision, without specific plans in place and resources identified for 
implementing it.

Andrew
-- 
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] how does Inspektr inability to write to RDBMS cause SWF conversation deadlock?

[Andrew Petro]

Kim,

Inspektr inability to insert records causing actions undertaken as part 
of Spring Web Flow conversations to hang (causing subsequent requests to 
access those conversations to wait on the lock for the conversation, 
thereby tying up Tomcat request processing threads out to exhaustion and 
thereby causing the CAS server to become nonresponsive) is an 
interesting hypothesis.


However, I'm wondering why Inspektr's use of asynchronous database 
access doesn't prevent this from tying up any conversations?


Inspektr's JDBC-using audit trail manager:

https://github.com/dima767/inspektr/blob/inspektr-1.0.0.GA/inspektr-support-spring/src/main/java/com/github/inspektr/audit/support/JdbcAuditTrailManager.java

uses

/** ExecutorService that has one thread to asynchronously save requests. */
private final ExecutorService executorService = 
Executors.newSingleThreadExecutor();


to execute the logging to the database in a single asynchronous thread.


Since JdbcAuditTrailManager will in practice be a singleton, singly 
instantiated from auditTrailContext.xml , and since it instantiates a 
single thread ExecutorService once, there should be a singleton such 
ExecutorService such that at any given time only one thread will be 
working on writing Inspektr audit log entries to the database.


Is the hypothesis that these threads terminate abnormally without 
returning their database connection to the pool?  That's at least plausible:


http://download.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/Executors.html#newSingleThreadExecutor()

I get how that could exhaust the database connection pool (sort of; 
shouldn't it be testing these connections?), but I guess I still don't 
see how this locks any conversations, since the database access is 
happening in a separate thread from that operating on the conversation.  
Mostly, audit trail logging should be able to fail in arbitrarily 
horrible ways and only have the consequence of failing to log the audit 
trail to the database.  [1]




Is this a matter of clean()

  public void clean() {
this.transactionTemplate.execute(new 
TransactionCallbackWithoutResult() { ...





not using that executor, such that clean() happens synchronously? (What 
calls clean(), anyway? That happening asynchronously in its own thread? 
Looks like doubly an exercise left to the reader -- firstly to get 
clean() to be called, and secondly default clean select SQL will select 
no records to be cleaned.)  I don't see offhand why clean() would be 
tying up the conversation -- if it's being called, how is that happening 
in a thread holding a SWF conversation?



Andrew


[1] (Maybe that's a disturbing thought, having a CAS server happily 
churning along servicing requests and *not* logging the audit trail as 
intended?)


On 02/14/2011 05:06 PM, Cary, Kim wrote:

Math, hi.

Our stuff is running on OSX server. I've seen several mysql databases (we put 
some log entries into mysql) stop accepting new entries when the db gets to the 
10Gb mark. No limit imposed by us, just empirically observed.

My wild guess is that maybe the inability to insert new records at that point 
caused a deadlock.

We're using queries for the audit data from Inspektr. Saved queries are handy. 
There is no built in managment gui for the data, but I imagine Crystal Reports 
would be handy.

Best,
KC

On Feb 14, 2011, at 11:38 AM, Matthew Selwood wrote:


Hi Kim,

I’m in the process of implemented Inspektr on our CAS build here.  What 10Gb 
threshold are you referred to? Is this a DB limit you’ve put in place?

On a similar note, is there a ‘user friendly’ way of viewing the database audit 
and stats, or do you just write queries?

Thanks,
Matt


---
Matthew Selwood
Programmer Analyst – Web Services
University of Victoria
250.472.5565 | selw...@uvic.ca | CLE C006

On 2/13/11 9:36 PM, "Cary, Kim"  wrote:

Our CAS service came up unresponsive (connection timed out) after throwing 
about 6 of these errors tonite.

Google doesn't have much on this, but one case shows some involvement with c3po 
failing to talk to the database. We use inspektr and our audit database hit a 
10Gb threshold tonite. Restarting tomcat without making any other changes put 
the service back into operation.

Can anyone share any clues on pursuing the root cause of the outage?

Thanks,
KC

Feb 13, 2011 7:12:03 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet cas threw exception
org.springframework.webflow.conversation.impl.LockTimeoutException: Unable to 
acquire conversation lock after 30 seconds
 at 
org.springframework.webflow.conversation.impl.JdkConcurrentConversationLock.lock(JdkConcurrentConversationLock.java:44)
 at 
org.springframework.webflow.conversation.impl.ContainedConversation.lock(ContainedConversation.java:69)
 at 
org.springframework.webflow.execution.repository.support.ConversationBackedFlowExecutionLock.lock(Conversati

Re: [cas-user] how does Inspektr inability to write to RDBMS cause SWF conversation deadlock?

[Andrew Petro]

> At the next report I'll be happy to dive in. If there are any other 
occurrences

> of this problem that haven't been reported, please speak up.

My current interest stems from this SWF conversation deadlock having 
apparently caused a production CAS server to become unresponsive on 
Tuesday, requiring Tomcat restart to resolve (which did resolve).


I don't have any interesting insights about the problem to share so far.

Andrew



--
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] Putting web.xml in my overlay causes runtime exception (version 3.4.5)

[Andrew Petro]

Bryan,

I can help you understand what the stack trace is saying, but I don't 
know why this problem is happening in your local environment without 
looking at your web.xml and local Spring configuration files.



web.xml declares a character encoding filter.

 
 characterEncodingFilter
 
org.springframework.web.filter.DelegatingFilterProxy
 



The Java Servlet Filter class that your servlet container (apparently, 
GlassFish) instantiates is a generic Spring-provided Filter 
(DelegatingFilterProxy) that then delegates to a bean wired up by 
Spring.  What bean? The bean with the same name as the filter.  So, the 
bean named "characterEncodingFilter".

Web.xml declares the listener that does this wiring and enumerates the 
(locations of) Spring configuration files.



org.jasig.cas.web.init.SafeContextLoaderListener





contextConfigLocation

/WEB-INF/spring-configuration/*.xml
/WEB-INF/deployerConfigContext.xml







What this stack trace is telling you is that there is no such bean named 
"characterEncodingFilter".

characterEncodingFilter is normally declared in 
/WEB-INF/spring-configuration/filters.xml

 



https://source.jasig.org/cas3/tags/cas-server-3.4.5/cas-server-webapp/src/main/webapp/WEB-INF/spring-configuration/filters.xml



So, at least one of these problems should be it:
1) your filters.xml does not declare  bean characterEncodingFilter.
2) your filters.xml does not exist at all (neither coming from the 
cas-server-war you're Maven overlaying upon nor coming from your local 
configuration)
3) your web.xml contextConfigLocation int-param is such that the paths 
or explicit files it enumerates doesn't include your filter.xml


As for how this is supposed to work: filters.xml is supposed to be 
coming from the war you're overlaying upon, such that you need do 
nothing and this Bean is just present and accounted for automatically.

Best wishes,

Andrew


On 06/20/2011 09:21 AM, Bryan Wooten wrote:
>
> When I put the web.xml in my overlay (exact copy of the one in 
> cas-server-webapp) I get the following error when I try and log in:
>
> [#|2011-06-20T07:16:07.061-0600|WARNING|glassfish3.0.1|javax.enterprise.system.container.web.com.sun.enterpri
>
> se.web|_ThreadID=27;_ThreadName=Thread-1;|StandardWrapperValve[default]: 
> PWC1406: Servlet.service() for servl
>
> et default threw exception
>
> org.springframework.beans.factory.NoSuchBeanDefinitionException: No 
> bean named 'characterEncodingFilter' is d
>
> efined
>
> at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeanDefinition(DefaultList
>
> ableBeanFactory.java:509)
>
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getMergedLocalBeanDefinition(Abstrac
>
> tBeanFactory.java:1041)
>
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:2
>
> 73)
>
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193
>
> )
>
> Any ideas what would cause this?
>
> Thanks,
>
> Bryan
>
> -- 
> You are currently subscribed to cas-user@lists.jasig.org as: ape...@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

[cas-user] document https-requiring-ness of single sign-on right in the login JSP UI?

[Andrew Petro]

Maybe the default ootb CAS login JSP should include a user-facing note 
to this effect of reminding folks trying out CAS that the SSO capability 
won't work without https (but basic login to one immediate webapp will)?

100% of adopters modify the login JSP to brand locally, so an 
easy-to-remove div wouldn't be that onerous on production adopters, and 
putting this documentation right-in-the-face of the casual demoer could 
make this nuance easier to understand.

I think this is a decent enough idea to warrant a JIRA.  Noted here:

https://issues.jasig.org/browse/CAS-991

Andrew


On 06/20/2011 07:36 AM, Scott Battaglia wrote:
>
> To enable single sign on, CAS must be running over https.
>
> On Jun 20, 2011 7:29 AM, "pionier"  > wrote:
> > Hi,
> > I have a problem with login to application that uses cas as auht 
> service. I have two apps (let say App1 and App2) when i login to cas 
> from App1 and then go to App2 (im not logged in in secod application) 
> when i try to login, standard cas login page is displayed. Whay is 
> that? is there some extra settings i have to do in order to be able to 
> auth via cas when i was allready loged in in another application? I 
> canot find any tutorial od documentation about that... can someone 
> point me where to start looking?
> > --
> > You are currently subscribed to cas-user@lists.jasig.org 
>  as: scott.battag...@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: ape...@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 is unavailable" when I stay too long on login page before submitting (CAS 3.4.8)

[Andrew Petro]

> I thought that this problem was solved a long time ago ??

Sounds like an opportunity to solve it again more thoroughly.

Here's my quick stab at a JIRA to track doing something deeper about this:

https://issues.jasig.org/browse/CAS-992

Andrew


On 06/20/2011 06:33 AM, Philippe MARASSE wrote:

Hello folks,

I've a problem similar to this one : 
https://issues.jasig.org/browse/CAS-700


When I stay too long on login page (more time, to get a session 
timeout about JSESSIONID), then submit a correct login/password, I get 
"CAS is unavailable" page, and an exception is thrown :


GRAVE: "Servlet.service()" pour la servlet cas a généré une exception
org.springframework.webflow.conversation.NoSuchConversationException: 
No conversation could be found with id '4' -- perhaps this 
conversation has ended?
at 
org.springframework.webflow.conversation.impl.ConversationContainer.getConversation(ConversationContainer.java:134)
at 
org.springframework.webflow.conversation.impl.SessionBindingConversationManager.getConversation(SessionBindingConversationManager.java:116)
at 
org.springframework.webflow.execution.repository.support.AbstractFlowExecutionRepository.getConversation(AbstractFlowExecutionRepository.java:183)
at 
org.jasig.cas.web.flow.CasFlowExecutionKeyFactory.validateUUID(CasFlowExecutionKeyFactory.java:138)
at 
org.jasig.cas.web.flow.CasFlowExecutionKeyFactory.parseFlowExecutionKey(CasFlowExecutionKeyFactory.java:102)
at 
org.springframework.webflow.executor.FlowExecutorImpl.resumeExecution(FlowExecutorImpl.java:164)
at 
org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.handle(FlowHandlerAdapter.java:183)
at 
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:790)
at 
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:719)
at 
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:644)
at 
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:560)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at 
org.jasig.cas.web.init.SafeDispatcherServlet.service_aroundBody2(SafeDispatcherServlet.java:115)
at 
org.jasig.cas.web.init.SafeDispatcherServlet.service_aroundBody3$advice(SafeDispatcherServlet.java:44)
at 
org.jasig.cas.web.init.SafeDispatcherServlet.service(SafeDispatcherServlet.java:1)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
com.github.inspektr.common.web.ClientInfoThreadLocalFilter.doFilter(ClientInfoThreadLocalFilter.java:63)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
at 
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at 
org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237)
at 
org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
at 
org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at 
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
at 
org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:776)
at 
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:705)
at 
org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:898)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)

at java.lang.Thread.run(Thread.java:662)

I thought that this problem was solved a long time ago ??

Rgds.




--
You are currently subscribed to cas-user@lists.j

[cas-user] AuthenticationHandler hanging forever causes SpringWebFlow deadlock

[Andrew Petro]

Ok.  I think I can make this exception happen by introducing a custom 
AuthenticationHandler that simply hangs forever.


At least, I started getting this in a terribly messy log at the TRACE 
level.  ootb cas-server 3.4.8 with only the custom loop-forever 
authentication handler introduced.


[

2011-06-20 16:13:02,558 TRACE 
[org.jasig.cas.web.NoSuchFlowExecutionExceptionResolver] - Entering 
method [resolveException with arguments 
[[org.apache.catalina.connector.RequestFacade@5889949a, 
org.apache.catalina.connector.ResponseFacade@307b37df, 
[FlowHandlerMapping.DefaultFlowHandler@da3a52c], 
org.springframework.webflow.conversation.impl.LockTimeoutException: 
Unable to acquire conversation lock after 30 seconds]]
2011-06-20 16:13:02,558 TRACE 
[org.jasig.cas.web.NoSuchFlowExecutionExceptionResolver] - Leaving 
method [resolveException] with return value [null].


]

Looks to me like it only hangs one thread and no other threads manage to 
even get to the authentication handler, though I submitted a handful of 
login form posts from a couple of browsers.


I'll gin up a quick HangsJustOneThreadForeverAuthenticationHandler to 
prove that it only takes one.


Andrew




Math, hi.

Our stuff is running on OSX server. I've seen several mysql databases (we put 
some log entries into mysql) stop accepting new entries when the db gets to the 
10Gb mark. No limit imposed by us, just empirically observed.

My wild guess is that maybe the inability to insert new records at that point 
caused a deadlock.

We're using queries for the audit data from Inspektr. Saved queries are handy. 
There is no built in managment gui for the data, but I imagine Crystal Reports 
would be handy.

Best,
KC

On Feb 14, 2011, at 11:38 AM, Matthew Selwood wrote:


Hi Kim,

I’m in the process of implemented Inspektr on our CAS build here.  What 10Gb 
threshold are you referred to? Is this a DB limit you’ve put in place?

On a similar note, is there a ‘user friendly’ way of viewing the database audit 
and stats, or do you just write queries?

Thanks,
Matt


---
Matthew Selwood
Programmer Analyst – Web Services
University of Victoria
250.472.5565 | selw...@uvic.ca | CLE C006

On 2/13/11 9:36 PM, "Cary, Kim"  wrote:

Our CAS service came up unresponsive (connection timed out) after throwing 
about 6 of these errors tonite.

Google doesn't have much on this, but one case shows some involvement with c3po 
failing to talk to the database. We use inspektr and our audit database hit a 
10Gb threshold tonite. Restarting tomcat without making any other changes put 
the service back into operation.

Can anyone share any clues on pursuing the root cause of the outage?

Thanks,
KC

Feb 13, 2011 7:12:03 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet cas threw exception
org.springframework.webflow.conversation.impl.LockTimeoutException: Unable to 
acquire conversation lock after 30 seconds
 at 
org.springframework.webflow.conversation.impl.JdkConcurrentConversationLock.lock(JdkConcurrentConversationLock.java:44)
 at 
org.springframework.webflow.conversation.impl.ContainedConversation.lock(ContainedConversation.java:69)
 at 
org.springframework.webflow.execution.repository.support.ConversationBackedFlowExecutionLock.lock(ConversationBackedFlowExecutionLock.java:51)
 at 
org.springframework.webflow.executor.FlowExecutorImpl.resumeExecution(FlowExecutorImpl.java:160)
 at 
org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.handle(FlowHandlerAdapter.java:183)
 at 
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:771)
 at 
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:716)
 at 
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:647)
 at 
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:563)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at 
org.jasig.cas.web.init.SafeDispatcherServlet.service_aroundBody2(SafeDispatcherServlet.java:115)
 at 
org.jasig.cas.web.init.SafeDispatcherServlet.service_aroundBody3$advice(SafeDispatcherServlet.java:44)
 at 
org.jasig.cas.web.init.SafeDispatcherServlet.service(SafeDispatcherServlet.java:1)
 at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at 
com.github.inspektr.common.web.ClientInfoThreadLocalFilter.doFilter(ClientInfoThreadLocalFilter.java:46)
 at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCha

Re: [cas-user] AuthenticationHandler hanging forever causes SpringWebFlow deadlock

[Andrew Petro]

Yup.  It only takes one AuthenticationHandler hung thread to block 
further requests from even trying to authenticate.


Opened a JIRA and attached a simple Maven Overlay demonstrating the issue.

https://issues.jasig.org/browse/CAS-993

I'll move discussion of what to do about this over to cas-dev.

This tends to support a hypothesis that when this conversation deadlock 
happened last week, it was an AuthenticationHandler that had started 
responding really slowly, thereby hanging on to this lock for a long time.


Andrew


Ok.  I think I can make this exception happen by introducing a custom 
AuthenticationHandler that simply hangs forever.


At least, I started getting this in a terribly messy log at the TRACE 
level.  ootb cas-server 3.4.8 with only the custom loop-forever 
authentication handler introduced.


[

2011-06-20 16:13:02,558 TRACE 
[org.jasig.cas.web.NoSuchFlowExecutionExceptionResolver] - Entering 
method [resolveException with arguments 
[[org.apache.catalina.connector.RequestFacade@5889949a, 
org.apache.catalina.connector.ResponseFacade@307b37df, 
[FlowHandlerMapping.DefaultFlowHandler@da3a52c], 
org.springframework.webflow.conversation.impl.LockTimeoutException: 
Unable to acquire conversation lock after 30 seconds]]
2011-06-20 16:13:02,558 TRACE 
[org.jasig.cas.web.NoSuchFlowExecutionExceptionResolver] - Leaving 
method [resolveException] with return value [null].


]

Looks to me like it only hangs one thread and no other threads manage 
to even get to the authentication handler, though I submitted a 
handful of login form posts from a couple of browsers.


I'll gin up a quick HangsJustOneThreadForeverAuthenticationHandler to 
prove that it only takes one.


Andrew




Math, hi.

Our stuff is running on OSX server. I've seen several mysql databases 
(we put some log entries into mysql) stop accepting new entries when 
the db gets to the 10Gb mark. No limit imposed by us, just 
empirically observed.


My wild guess is that maybe the inability to insert new records at 
that point caused a deadlock.


We're using queries for the audit data from Inspektr. Saved queries 
are handy. There is no built in managment gui for the data, but I 
imagine Crystal Reports would be handy.


Best,
KC

On Feb 14, 2011, at 11:38 AM, Matthew Selwood wrote:


Hi Kim,

I’m in the process of implemented Inspektr on our CAS build here.  
What 10Gb threshold are you referred to? Is this a DB limit you’ve 
put in place?


On a similar note, is there a ‘user friendly’ way of viewing the 
database audit and stats, or do you just write queries?


Thanks,
Matt


---
Matthew Selwood
Programmer Analyst – Web Services
University of Victoria
250.472.5565 | selw...@uvic.ca | CLE C006

On 2/13/11 9:36 PM, "Cary, Kim"  wrote:

Our CAS service came up unresponsive (connection timed out) after 
throwing about 6 of these errors tonite.


Google doesn't have much on this, but one case shows some 
involvement with c3po failing to talk to the database. We use 
inspektr and our audit database hit a 10Gb threshold tonite. 
Restarting tomcat without making any other changes put the service 
back into operation.


Can anyone share any clues on pursuing the root cause of the outage?

Thanks,
KC

Feb 13, 2011 7:12:03 PM 
org.apache.catalina.core.StandardWrapperValve invoke

SEVERE: Servlet.service() for servlet cas threw exception
org.springframework.webflow.conversation.impl.LockTimeoutException: 
Unable to acquire conversation lock after 30 seconds
 at 
org.springframework.webflow.conversation.impl.JdkConcurrentConversationLock.lock(JdkConcurrentConversationLock.java:44)
 at 
org.springframework.webflow.conversation.impl.ContainedConversation.lock(ContainedConversation.java:69)
 at 
org.springframework.webflow.execution.repository.support.ConversationBackedFlowExecutionLock.lock(ConversationBackedFlowExecutionLock.java:51)
 at 
org.springframework.webflow.executor.FlowExecutorImpl.resumeExecution(FlowExecutorImpl.java:160)
 at 
org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.handle(FlowHandlerAdapter.java:183)
 at 
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:771)
 at 
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:716)
 at 
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:647)
 at 
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:563)
 at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
 at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at 
org.jasig.cas.web.init.SafeDispatcherServlet.service_aroundBody2(SafeDispatcherServlet.java:115)
 at 
org.jasig.cas.web.init.SafeDispatcherServlet.service_aroundBody3$advice(SafeDispatcherServlet.java:44)
 at 
org.jasig.cas.web.init.SafeDispatcherServlet.service(SafeDispatcherServ

Re: [cas-user] AuthenticationHandler hanging forever causes SpringWebFlow conversation lock acquisition timeout

[Andrew Petro]

Sorry, it's more complicated than I'd thought.  An embarrassing 
synchronization bug in my example made the consequences of the problem 
worse.  One hung AuthenticationHandler isn't sufficient to deadlock the 
CAS web flow for everyone.


Poking at it further...

Andrew



On 06/20/2011 05:41 PM, Andrew Petro wrote:
Yup.  It only takes one AuthenticationHandler hung thread to block 
further requests from even trying to authenticate.


Opened a JIRA and attached a simple Maven Overlay demonstrating the 
issue.


https://issues.jasig.org/browse/CAS-993

I'll move discussion of what to do about this over to cas-dev.

This tends to support a hypothesis that when this conversation 
deadlock happened last week, it was an AuthenticationHandler that had 
started responding really slowly, thereby hanging on to this lock for 
a long time.


Andrew


Ok.  I think I can make this exception happen by introducing a custom 
AuthenticationHandler that simply hangs forever.


At least, I started getting this in a terribly messy log at the TRACE 
level.  ootb cas-server 3.4.8 with only the custom loop-forever 
authentication handler introduced.


[

2011-06-20 16:13:02,558 TRACE 
[org.jasig.cas.web.NoSuchFlowExecutionExceptionResolver] - Entering 
method [resolveException with arguments 
[[org.apache.catalina.connector.RequestFacade@5889949a, 
org.apache.catalina.connector.ResponseFacade@307b37df, 
[FlowHandlerMapping.DefaultFlowHandler@da3a52c], 
org.springframework.webflow.conversation.impl.LockTimeoutException: 
Unable to acquire conversation lock after 30 seconds]]
2011-06-20 16:13:02,558 TRACE 
[org.jasig.cas.web.NoSuchFlowExecutionExceptionResolver] - Leaving 
method [resolveException] with return value [null].


]

Looks to me like it only hangs one thread and no other threads manage 
to even get to the authentication handler, though I submitted a 
handful of login form posts from a couple of browsers.


I'll gin up a quick HangsJustOneThreadForeverAuthenticationHandler to 
prove that it only takes one.


Andrew




Math, hi.

Our stuff is running on OSX server. I've seen several mysql 
databases (we put some log entries into mysql) stop accepting new 
entries when the db gets to the 10Gb mark. No limit imposed by us, 
just empirically observed.


My wild guess is that maybe the inability to insert new records at 
that point caused a deadlock.


We're using queries for the audit data from Inspektr. Saved queries 
are handy. There is no built in managment gui for the data, but I 
imagine Crystal Reports would be handy.


Best,
KC

On Feb 14, 2011, at 11:38 AM, Matthew Selwood wrote:


Hi Kim,

I’m in the process of implemented Inspektr on our CAS build here.  
What 10Gb threshold are you referred to? Is this a DB limit you’ve 
put in place?


On a similar note, is there a ‘user friendly’ way of viewing the 
database audit and stats, or do you just write queries?


Thanks,
Matt


---
Matthew Selwood
Programmer Analyst – Web Services
University of Victoria
250.472.5565 | selw...@uvic.ca | CLE C006

On 2/13/11 9:36 PM, "Cary, Kim"  wrote:

Our CAS service came up unresponsive (connection timed out) after 
throwing about 6 of these errors tonite.


Google doesn't have much on this, but one case shows some 
involvement with c3po failing to talk to the database. We use 
inspektr and our audit database hit a 10Gb threshold tonite. 
Restarting tomcat without making any other changes put the service 
back into operation.


Can anyone share any clues on pursuing the root cause of the outage?

Thanks,
KC

Feb 13, 2011 7:12:03 PM 
org.apache.catalina.core.StandardWrapperValve invoke

SEVERE: Servlet.service() for servlet cas threw exception
org.springframework.webflow.conversation.impl.LockTimeoutException: 
Unable to acquire conversation lock after 30 seconds
 at 
org.springframework.webflow.conversation.impl.JdkConcurrentConversationLock.lock(JdkConcurrentConversationLock.java:44)
 at 
org.springframework.webflow.conversation.impl.ContainedConversation.lock(ContainedConversation.java:69)
 at 
org.springframework.webflow.execution.repository.support.ConversationBackedFlowExecutionLock.lock(ConversationBackedFlowExecutionLock.java:51)
 at 
org.springframework.webflow.executor.FlowExecutorImpl.resumeExecution(FlowExecutorImpl.java:160)
 at 
org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.handle(FlowHandlerAdapter.java:183)
 at 
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:771)
 at 
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:716)
 at 
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:647)
 at 
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:563)
 at 
javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
 

Re: [cas-user] document https-requiring-ness of single sign-on right in the login JSP UI?

[Andrew Petro]

Marvin,

> the default UI should be focused on
> authentication, not communicating to deployers.

I disagree thoroughly.  The default login UI should be focused on 
communicating to and enabling the success of CAS deployers, not 
communicating with end users.


This would poison the user experience for 0% of users since all adopters 
customize the login screen.  Rather, this would hone the experience for 
100% of the real audience of that page as shipped in the CAS server 
release (the deployers).  In fact, I'll suggest going further to make 
the default login.jsp more "meta", perhaps adding notes/placeholders for 
the sorts of things most adopters will want to add to that page, like 
messaging about whom to contact if you don't have an account / forgot 
your password / need technical support.


Looks like VT has a locally customized login jsp, well-managed in SVN:

https://svn.middleware.vt.edu/svn/middleware/cas/cas-server/trunk/vt-cas-server-webapp/src/main/webapp/WEB-INF/view/jsp/vt/ui/casLoginView.jsp

doubtless many adopters are managing this less rigorously, but I doubt 
anyone isn't modifying that page.



Does *anyone* out there have an unmodified login jsp such that having to 
remove this messaging adds additional local modification maintenance 
burden?  I'm often wrong, feel free to speak up and show me wrong now. :)


Andrew


On 06/21/2011 11:25 AM, Marvin Addison wrote:

Maybe the default ootb CAS login JSP should include a user-facing note to
this effect of reminding folks trying out CAS that the SSO capability won't
work without https (but basic login to one immediate webapp will)?

I'm ambivalent about this.  I understand the reasoning: it's a vitally
important point that deployers should understand and placing it in
their face on the login screen will make it unavoidable.  However,
you're poisoning the user experience for 99.9% of users when the
intended audience is the handful of deployers responsible for the
application.

I'd like to consider other ways to communicate this information.
While it's easy enough to remove, the default UI should be focused on
authentication, not communicating to deployers.

M




--
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] document https-requiring-ness of single sign-on right in the login JSP UI?

[Andrew Petro]

> Agree to disagree, then.

With a great deal of respect, certainly, but I guess I'm not yet 
relating to your perspective on this and am not yet ready to give up on 
understanding one another.


What happens in a CAS deployment is that the login JSP files are input 
to creative professionals who then customize the JSP, craft the markup 
and CSS and even JavaScript, apply the institutional brand, and get to 
the central login experience for the institution adopting CAS, right?  
Some of these professionals are familiar with JSP, many are not but cope 
fine because it mostly looks like HTML.


I don't relate to the allusion to an installer.  No installer wizard 
would be sufficient to get to a login UI appropriate to the central 
authentication brand of most CAS adopters.


I don't think we need an installation wizard to generate the login UI, 
at least not as the incremental improvement.  Just better starting JSP 
templates that are more helpful to the adopters starting from those 
templates.


uPortal ships with a default UI that lists example username/password 
pairs right on the not-yet-logged-in user experience.  This is sensible 
because everyone who sees that default experience is a new adopter 
getting started with a uPortal install -- by the time any end users see 
it, that not logged in experience has been honed to the content, 
portlets, experience that reflects what the portal has to say to 
not-yet-logged-in users.  CAS is like that but less so.


Andrew


On 06/21/2011 11:57 AM, Marvin Addison wrote:

The default login UI should be focused on
communicating to and enabling the success of CAS deployers, not
communicating with end users.

Agree to disagree, then.


In fact, I'll suggest going further to make the default
login.jsp more "meta", perhaps adding notes/placeholders for the sorts of
things most adopters will want to add to that page, like messaging about
whom to contact if you don't have an account / forgot your password / need
technical support.

Good suggestions with the wrong target.  These belong in a guided
installation process, not the default UI.  In the Windows world, these
are captured in a wizard-driven installer, not the product itself.

M




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