deploy cas server and cas client on two machines
Scott Battaglia
scott.battaglia at gmail.com
Thu Apr 24 09:30:21 EDT 2008
Did you add the certificate to the JVM's keystore?
-Scott
2008/4/23 qingzhao zheng <qingzhaoz at yahoo.com.cn>:
> thank you jack,I add the keyAlias="tcmsso2" in the server.xml,
> <Connector protocol="org.apache.coyote.http11.Http11Protocol"
> port="8443" minSpareThreads="5" maxSpareThreads="75"
> enableLookups="false" disableUploadTimeout="true"
> acceptCount="100" maxThreads="200"
> scheme="https" secure="true" SSLEnabled="true"
> keystoreFile="/tcmserver2.keystore" keystorePass="changeit"
> truststoreFile="C:/jre1.5.0_07/lib/security/cacerts"
> keyAlias="tcmsso2" clientAuth="false" sslProtocol="TLS"/>
> after I restart tomcat,it still doesn't work.
> and the total error message is as follow:
> exception
> javax.servlet.ServletException: sun.security.validator.ValidatorException:
> PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
>
> edu.yale.its.tp.cas.client.filter.CASFilter.getAuthenticatedUser(CASFilter.java:254)
> edu.yale.its.tp.cas.client.filter.CASFilter.doFilter(CASFilter.java:184)
> filters.ExampleFilter.doFilter(ExampleFilter.java:102)
> root cause
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(Unknown Source)
> com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source)
> com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source)
> com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Unknown
> Source)
> com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown
> Source)
> com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
> com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown Source)
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown
> Source)
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
> sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown
> Source)
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
> sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown
> Source)
> edu.yale.its.tp.cas.util.SecureURL.retrieve(SecureURL.java:70)
>
> edu.yale.its.tp.cas.client.ServiceTicketValidator.validate(ServiceTicketValidator.java:212)
>
> edu.yale.its.tp.cas.client.filter.CASFilter.getAuthenticatedUser(CASFilter.java:219)
> edu.yale.its.tp.cas.client.filter.CASFilter.doFilter(CASFilter.java:184)
> filters.ExampleFilter.doFilter(ExampleFilter.java:102)
> root cause
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> sun.security.validator.PKIXValidator.doBuild(Unknown Source)
> sun.security.validator.PKIXValidator.engineValidate(Unknown Source)
> sun.security.validator.Validator.validate(Unknown Source)
> com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.validate(Unknown Source)
> com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown
> Source)
> com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown
> Source)
> com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Unknown
> Source)
> com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown
> Source)
> com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
> com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown Source)
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown
> Source)
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
> sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown
> Source)
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
> sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown
> Source)
> edu.yale.its.tp.cas.util.SecureURL.retrieve(SecureURL.java:70)
>
> edu.yale.its.tp.cas.client.ServiceTicketValidator.validate(ServiceTicketValidator.java:212)
>
> edu.yale.its.tp.cas.client.filter.CASFilter.getAuthenticatedUser(CASFilter.java:219)
> edu.yale.its.tp.cas.client.filter.CASFilter.doFilter(CASFilter.java:184)
> filters.ExampleFilter.doFilter(ExampleFilter.java:102)
> root cause
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(Unknown
> Source)
> java.security.cert.CertPathBuilder.build(Unknown Source)
> sun.security.validator.PKIXValidator.doBuild(Unknown Source)
> sun.security.validator.PKIXValidator.engineValidate(Unknown Source)
> sun.security.validator.Validator.validate(Unknown Source)
> com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.validate(Unknown Source)
> com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown
> Source)
> com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown
> Source)
> com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Unknown
> Source)
> com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown
> Source)
> com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
> com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown Source)
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown
> Source)
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
> com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
> sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
> sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown
> Source)
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
> sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown
> Source)
> edu.yale.its.tp.cas.util.SecureURL.retrieve(SecureURL.java:70)
>
> edu.yale.its.tp.cas.client.ServiceTicketValidator.validate(ServiceTicketValidator.java:212)
>
> edu.yale.its.tp.cas.client.filter.CASFilter.getAuthenticatedUser(CASFilter.java:219)
> edu.yale.its.tp.cas.client.filter.CASFilter.doFilter(CASFilter.java:184)
> filters.ExampleFilter.doFilter(ExampleFilter.java:102)
> note The full stack trace of the root cause is available in the Apache
> Tomcat/5.5.23 logs.
>
>
> *cas-request at tp.its.yale.edu* дµÀ£º
>
> Send cas mailing list submissions to
> cas at tp.its.yale.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://tp.its.yale.edu/mailman/listinfo/cas
> or, via email, send a message with subject or body 'help' to
> cas-request at tp.its.yale.edu
>
> You can reach the person managing the list at
> cas-owner at tp.its.yale.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cas digest..."
>
>
> Today's Topics:
>
> 1. Re: Ability to specify demand on Level of Assurance in the
> authentication request (Scott Battaglia)
> 2. CAS Feature (Trenton D. Adams)
> 3. Re: deploy cas server and cas client on two machines (Jack HC LEE)
> 4. Service dependent CredentialsToPrincipalResolver
> (Sudirikku Mohanjith)
> 5. SV: Ability to specify demand on Level of Assurance in the
> authentication request (P?l Axelsson)
> 6. RE: CAS Feature (Andrew R Feller)
> 7. CredentialsToLDAPAttributePrincipalResolverTests error
> (Julien Garnier)
> 8. Re: Running CAS in a cluster on JBOSS (Scott Marshall)
> 9. Re: CAS Feature (Trenton D. Adams)
> 10. RE: CAS Feature (Andrew R Feller)
> 11. Re: CAS Feature (Trenton D. Adams)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 22 Apr 2008 22:05:00 -0400
> From: "Scott Battaglia"
> Subject: Re: Ability to specify demand on Level of Assurance in the
> authentication request
> To: "Yale CAS mailing list"
> Message-ID:
> <1bbd36a10804221905w687538feh1fa159010d55a464 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> Sorry for the delayed response on this. It got lost in some emails. This
> seems like an interesting feature. We're currently gathering ideas for the
> next major version of CAS (we have a wishlist in the wiki). If you can add
> any details to the wishlist about this feature (maybe just copy in the
> whole
> email ;-)) that would be great. We can't make any guarantees on what will
> be in the next version. Just because its on the wishlist doesn't mean it
> will get in, but its the best place to keep track of these (or as a JIRA
> issue).
>
> Thanks!
> -Scott
>
> On Wed, Apr 2, 2008 at 3:49 PM, P?l Axelsson wrote:
>
> > Hi,
> >
> >
> >
> > The reason I write this mail is that some of us CAS users in Sweden has
> > found that different application needs different assurance levels
> regarding
> > the authentication handler and the user identity. For example a
> personalized
> > page may just need an simple self asserted identity, a student portal
> need
> > an proofed identity with a username and password login and a web page
> where
> > examiner report the students results may need a onetime password (OTP) or
> > certificate login. What we can see there is a good "industry standard"
> for
> > level of assurance in the combination of OMB M-04-04 (
> > http://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdf) and NIST
> SP800-63
> > (http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf).
> To
> > go the technical way to say that we demand OTP for login or
> > username/password for login due to the fact that the login technique
> changes
> > via time and is a question for the CAS server not the application server.
> So
> > what we want to do is to make CAS level of assurance aware and we want to
> > hear what the rest of the CAS community has to say about this idea. And
> if
> > it's feasibly to include in CAS.
> >
> >
> >
> > To use multiple CAS installations to accommodate this functionality is
> not
> > a very good solution due to that than you need to install, configure and
> > support multiple CAS installations. Furthermore the application deployers
> > must think more than once when they configure which CAS server that
> should
> > be used for the application.
> >
> >
> >
> > The solution is to add an optional parameter demandLoA to the /login
> > credential requestor to demand a lowest combined level of assurance for
> the
> > authentication. The combined level of assurance in this scenario is the
> > lowest level of assurance of the areas registration and identity
> proofing,
> > credential management and tokens used for proving identity. The other two
> > areas in NIST level of assurance must be seen in the light of CAS itself.
> If
> > the optional parameter is not available in the /login URI then a
> predefined
> > level of assurance should be used.
> >
> >
> >
> > To evaluate the registration and identity proofing level of assurance CAS
> > need to know about under what level of assurance a specific user got his
> > electronic identity. This can be done for example via the LDAP attribute
> > defined in FAME-PERMIS Definition of the LoA Attribute (
> > http://www.fame-permis.org/loa.html) or predefined for all users in the
> > configuration for CAS.
> >
> >
> >
> > To set the level of assurance for credential management I think it should
> > be sufficient to predefine it in the configuration per identity provider
> > that is used in the CAS installation.
> >
> >
> >
> > What authentication handler, or handlers, that is valid for each level of
> > assurance should be defined in the configuration of CAS.
> >
> >
> >
> > The login page must be configured to handle multiple authentication
> > handlers and present a choice of authentication handler where the
> combined
> > level of assurance is equal or higher than the demanded level of
> assurance.
> >
> >
> >
> >
> >
> > P?l Axelsson, Uppsala universitet, for SWAMI* CAS Special Interest Group
> >
> > *Swedish Alliance for Middleware Infrastructure, SWAMI, is the
> > organization for middleware cooperation in the Swedish higher education
> > community. (http://www.swami.se)
> >
> >
> >
> > _______________________________________________
> > Yale CAS mailing list
> > cas at tp.its.yale.edu
> > http://tp.its.yale.edu/mailman/listinfo/cas
> >
> >
>
>
> --
> -Scott Battaglia
> PGP Public Key Id: 0x383733AA
> LinkedIn: http://www.linkedin.com/in/scottbattaglia
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://tp.its.yale.edu/pipermail/cas/attachments/20080422/9c10fa6b/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Tue, 22 Apr 2008 20:44:24 -0600 (MDT)
> From: "Trenton D. Adams"
> Subject: CAS Feature
> To: Yale CAS mailing list
> Message-ID:
> <1660667684.17841208918664433.JavaMail.root at avocado.cs.athabascau.ca>
> Content-Type: text/plain; charset=utf-8
>
> Hi Guys,
>
> Does CAS have a feature that will allow timeouts to be different by user id
> and IP address or range?
>
> I wrote a feature recently for 2.0.11 that allows a regular expression for
> both the user id and the IP address. Basically, we don't want internal staff
> timing out any time soon, but we do want students to time out earlier than
> staff. And we also want staff that are external to timeout VERY quickly.
>
> Is there a feature such as this, or is it on the wish list?
>
> Thanks.
>
> __
> This communication is intended for the use of the recipient to whom it
> is addressed, and may contain confidential, personal, and or privileged
> information. Please contact us immediately if you are not the intended
> recipient of this communication, and do not copy, distribute, or take
> action relying on it. Any communications received in error, or
> subsequent reply, should be deleted or destroyed.
> ---
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 23 Apr 2008 15:58:41 +0800
> From: Jack HC LEE
> Subject: Re: deploy cas server and cas client on two machines
> To: Yale CAS mailing list
> Message-ID: <480EEC31.2040004 at ust.hk>
> Content-Type: text/plain; charset=GB2312
>
> Dear QingZhao,
>
> You may have forget to set the right keyAlias attribute (i.e.
> keyAlias="tscmsso2") in your server.xml element
>
>
> regards,
>
> Jack
>
>
>
> qingzhao zheng wrote:
> > Hi,
> > I deploy cas server and cas client on two machines,and when I visit
> > the HelloWorldExample ,it redirect to the login page,
> > after I enter the name/password.it return to the HelloworldExample
> > page with ticket ,but throw a exception.
> > exception
> > javax.servlet.ServletException:
> > sun.security.validator.ValidatorException: PKIX path building failed:
> > sun.security.provider.certpath.SunCertPathBuilderException: unable to
> > find valid certification path to requested target
> >
> edu.yale.its.tp.cas.client.filter.CASFilter.getAuthenticatedUser(CASFilter.java:254)
> > edu.yale.its.tp.cas.client.filter.CASFilter.doFilter(CASFilter.java:184)
> > filters.ExampleFilter.doFilter(ExampleFilter.java:102)
> >
> > root cause
> > javax.net.ssl.SSLHandshakeException:
> > sun.security.validator.ValidatorException: PKIX path building failed:
> > sun.security.provider.certpath.SunCertPathBuilderException: unable to
> > find valid certification path to requested target
> > the situation is:
> > cas server is on machine1(computer name:qing),cas server is under
> > tomcat5/webapps
> > I make certifacte like this:
> > keytool -genkey -keyalg RSA -alias tcmsso2 -dname "cn=qing" -keystore
> > tcmserver2.keystore -storepass changeit
> > keytool -export -alias tcmsso2 -keystore tcmserver2.keystore -file
> > C:/jre1.5.0_07/lib/security/tcmsso2.crt -storepass changeit
> > keytool -import -alias tcmsso2 -file
> > C:/jre1.5.0_07/lib/security/tcmsso2.crt -keystore
> > C:/jre1.5.0_07/lib/security/cacerts -storepass changeit
> > I config machine1's tomcat like this:
> > > port="8443" minSpareThreads="5" maxSpareThreads="75"
> > enableLookups="false" disableUploadTimeout="true"
> > acceptCount="100" maxThreads="200"
> > scheme="https" secure="true" SSLEnabled="true"
> > keystoreFile="/tcmserver2.keystore" keystorePass="changeit"
> > truststoreFile="C:/jre1.5.0_07/lib/security/cacerts"
> > clientAuth="false" sslProtocol="TLS"/>
> > cas client is on machine2(computer name:wjj),cas client is under
> > tomcat5/webapps
> > I put cas-client.jar under webapps/servlets-examples/WEB-INF/lib,
> > config the web.xml as such:
> >
> > CAS Filter
> > edu.yale.its.tp.cas.client.filter.CASFilter
> >
> > edu.yale.its.tp.cas.client.filter.loginUrl
> > https://qing:8443/cas/login
> >
> >
> > edu.yale.its.tp.cas.client.filter.validateUrl
> > https://qing:8443/cas/serviceValidate
> >
> >
> > edu.yale.its.tp.cas.client.filter.serverName
> > wjj:8888
> >
> >
> > and import the server's certificate.
> > keytool -import -alias tcmsso2 -file
> > C:/jre1.5.0_07/lib/security/tcmsso2.crt -keystore
> > C:/jre1.5.0_07/lib/security/cacerts -storepass changeit
> > both machines are run windows XP ,for cas does not support ip;
> > I add 10.214.33.211 qing to the C:\WINDOWS\system32\drivers\etc\hosts
> > on machine1
> > and add 10.214.33.211 qing 10.214.33.156 wjj to the
> > C:\WINDOWS\system32\drivers\etc\hosts on machine2
> > strangely,if the cas server and cas client are on the same machine
> > ,they works well.
> > Is there something wrong?
> > Thanks for your help,
> > qingzhao
> >
> > ------------------------------------------------------------------------
> > ????????????????????????
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Yale CAS mailing list
> > cas at tp.its.yale.edu
> > http://tp.its.yale.edu/mailman/listinfo/cas
> >
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 23 Apr 2008 14:05:36 +0530
> From: "Sudirikku Mohanjith"
> Subject: Service dependent CredentialsToPrincipalResolver
> To: "Yale CAS mailing list"
> Message-ID:
>
> Content-Type: text/plain; charset=UTF-8
>
> Hi,
> I want the Principal (specifically id) to be different depeding on the
> Service requesting authentication. This need is because we have 3
> services(web applications) that we want to use CAS for authentication,
> but some users have different usernames for the 3 services. We plan to
> allow the users to claim the accounts and use one set of credentials
> to authenticate against CAS and then CAS will present different NetIds
> depending on the service. Hope I'm clear.
>
> >From what I understand I need to create a new
> CredentialsToPrincipalResolver that will consider the Service as well
> to resolve the Principal. However I'm not sure whether I can findout
> the service requesting authentication.
>
> Any help is appreciated.
>
> Cheers,
> Mohanjith
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 23 Apr 2008 11:06:20 +0200
> From: P?l Axelsson
> Subject: SV: Ability to specify demand on Level of Assurance in the
> authentication request
> To: "'Yale CAS mailing list'"
> Cc: cas at swami.se
> Message-ID: <017001c8a521$4c233a20$e469ae60$@Axelsson at its.uu.se>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
>
>
> Thanks for the answer.
>
>
>
> I have now added ?Support for LoA? in the Wishlist.
>
>
>
> I have been informed that there is a work on LoA in eduPerson so that the
> implementation of LoA in CAS should harmonize with this.
>
>
>
> P?l Axelsson
>
>
>
>
>
> Fr?n: cas-bounces at tp.its.yale.edu [mailto:cas-bounces at tp.its.yale.edu] F?r
> Scott Battaglia
> Skickat: den 23 april 2008 04:05
> Till: Yale CAS mailing list
> ?mne: Re: Ability to specify demand on Level of Assurance in the
> authentication request
>
>
>
> Hi,
>
> Sorry for the delayed response on this. It got lost in some emails. This
> seems like an interesting feature. We're currently gathering ideas for the
> next major version of CAS (we have a wishlist in the wiki). If you can add
> any details to the wishlist about this feature (maybe just copy in the
> whole
> email ;-)) that would be great. We can't make any guarantees on what will
> be in the next version. Just because its on the wishlist doesn't mean it
> will get in, but its the best place to keep track of these (or as a JIRA
> issue).
>
> Thanks!
> -Scott
>
> On Wed, Apr 2, 2008 at 3:49 PM, P?l Axelsson wrote:
>
> Hi,
>
>
>
> The reason I write this mail is that some of us CAS users in Sweden has
> found that different application needs different assurance levels regarding
> the authentication handler and the user identity. For example a
> personalized
> page may just need an simple self asserted identity, a student portal need
> an proofed identity with a username and password login and a web page where
> examiner report the students results may need a onetime password (OTP) or
> certificate login. What we can see there is a good "industry standard" for
> level of assurance in the combination of OMB M-04-04
> (http://www.whitehouse.gov/omb/memoranda/fy04/m04-04.pdf) and NIST
> SP800-63
> (http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf). To
> go the technical way to say that we demand OTP for login or
> username/password for login due to the fact that the login technique
> changes
> via time and is a question for the CAS server not the application server.
> So
> what we want to do is to make CAS level of assurance aware and we want to
> hear what the rest of the CAS community has to say about this idea. And if
> it's feasibly to include in CAS.
>
>
>
> To use multiple CAS installations to accommodate this functionality is not
> a
> very good solution due to that than you need to install, configure and
> support multiple CAS installations. Furthermore the application deployers
> must think more than once when they configure which CAS server that should
> be used for the application.
>
>
>
> The solution is to add an optional parameter demandLoA to the /login
> credential requestor to demand a lowest combined level of assurance for the
> authentication. The combined level of assurance in this scenario is the
> lowest level of assurance of the areas registration and identity proofing,
> credential management and tokens used for proving identity. The other two
> areas in NIST level of assurance must be seen in the light of CAS itself.
> If
> the optional parameter is not available in the /login URI then a predefined
> level of assurance should be used.
>
>
>
> To evaluate the registration and identity proofing level of assurance CAS
> need to know about under what level of assurance a specific user got his
> electronic identity. This can be done for example via the LDAP attribute
> defined in FAME-PERMIS Definition of the LoA Attribute
> (http://www.fame-permis.org/loa.html) or predefined for all users in the
> configuration for CAS.
>
>
>
> To set the level of assurance for credential management I think it should
> be
> sufficient to predefine it in the configuration per identity provider that
> is used in the CAS installation.
>
>
>
> What authentication handler, or handlers, that is valid for each level of
> assurance should be defined in the configuration of CAS.
>
>
>
> The login page must be configured to handle multiple authentication
> handlers
> and present a choice of authentication handler where the combined level of
> assurance is equal or higher than the demanded level of assurance.
>
>
>
>
>
> P?l Axelsson, Uppsala universitet, for SWAMI* CAS Special Interest Group
>
> *Swedish Alliance for Middleware Infrastructure, SWAMI, is the organization
> for middleware cooperation in the Swedish higher education community.
> (http://www.swami.se)
>
>
>
>
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
>
>
>
> --
> -Scott Battaglia
> PGP Public Key Id: 0x383733AA
> LinkedIn: http://www.linkedin.com/in/scottbattaglia
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://tp.its.yale.edu/pipermail/cas/attachments/20080423/2f9def05/attachment-0001.html
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/x-pkcs7-signature
> Size: 4702 bytes
> Desc: not available
> Url :
> http://tp.its.yale.edu/pipermail/cas/attachments/20080423/2f9def05/attachment-0001.bin
>
> ------------------------------
>
> Message: 6
> Date: Wed, 23 Apr 2008 07:36:35 -0500
> From: "Andrew R Feller"
> Subject: RE: CAS Feature
> To: "Yale CAS mailing list"
> Message-ID: <1D5C148F9259BC47BC3CBD2F76ABA205EF740D at email002.lsu.edu>
> Content-Type: text/plain; charset="us-ascii"
>
> Trenton,
>
> Right now, you can only specify a single timeout policy for use with
> service tickets and ticket granting tickets, which the ticket granting
> ticket is used for the SSO portion of CAS. This is done in the
> cas-server-webapp/src/main/webapp/WEB-INF/spring-configuration/ticketExp
> irationPolicies.xml file of the 3.2 branch.
>
> Now, it might be possible for you to write your own timeout policy to do
> it. If you look in
> cas-server-core/src/main/java/org/jasig/cas/ticket/TicketState.java, you
> will see the getAuthentication() method, which returns an instance of
> cas-server-core/src/main/java/org/jasig/cas/authentication/Authenticatio
> n.java, which will allow you to use the getPrincipal() method.
>
> HTH,
>
> Andrew R Feller, Analyst
> University Information Systems
> 200 Fred Frey Building
> Louisiana State University
> Baton Rouge, LA, 70803
> (225) 578-3737 (Office)
> (225) 578-6400 (Fax)
>
> -----Original Message-----
> From: cas-bounces at tp.its.yale.edu [mailto:cas-bounces at tp.its.yale.edu]
> On Behalf Of Trenton D. Adams
> Sent: Tuesday, April 22, 2008 9:44 PM
> To: Yale CAS mailing list
> Subject: CAS Feature
>
> Hi Guys,
>
> Does CAS have a feature that will allow timeouts to be different by user
> id and IP address or range?
>
> I wrote a feature recently for 2.0.11 that allows a regular expression
> for both the user id and the IP address. Basically, we don't want
> internal staff timing out any time soon, but we do want students to time
> out earlier than staff. And we also want staff that are external to
> timeout VERY quickly.
>
> Is there a feature such as this, or is it on the wish list?
>
> Thanks.
>
> __
> This communication is intended for the use of the recipient to whom
> it
> is addressed, and may contain confidential, personal, and or
> privileged
> information. Please contact us immediately if you are not the
> intended
> recipient of this communication, and do not copy, distribute, or
> take
> action relying on it. Any communications received in error, or
> subsequent reply, should be deleted or destroyed.
> ---
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
>
> ------------------------------
>
>
> === message truncated ===
>
>
> ------------------------------
> ÑÅ»¢ÓÊÏ䣬ÄúµÄÖÕÉúÓÊÏ䣡 <http://cn.mail.yahoo.com/>
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>
>
--
-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20080424/3891bde9/attachment.html
More information about the cas
mailing list