[cas-user] pac4j oauth examples - getting error while accessing /accessToken api

[Mahantesh Prasad Katti]

Hi All,

I am playing around with the pac4j examples for oauth. I know that with oauth 
we can run the following apis.
1./oauth2.0/authorize
2. /oauth2.0/accessToken
3. /oauth2.0/profile
I am able to see the authorize call going through in the firebug. When I try to 
access /oauth2.0/accessToken api, with the appropriate input paramaters [as an 
example 
http://wlw7-mahanteshk:8080/cas2/oauth2.0/accessToken?code=OC-4-pwdvcGyEV6zDK46BWJ0V7YUAfD0qNDpOsnO_id=this_is_the_key_secret=this_is_the_secret_uri=http%3A%2F%2Flocalhost%3A8080%2Fcas%2Flogin%3Fclient_name%3DCasOAuthWrapperClient],
 I get the "invalid_request" with 400 status code.
Is there something I am missing here?
Regards,
Prasad


-- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/83FA22EE27AA7949A5F616D4DD6AF71E16ECAF11%40INBLRMBX001.INDECOMM.LOCAL.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

[cas-user] Proxy callback URL Exception

[David Lee]

Hi All,

Hope you all are doing great. 

I'm using CAS 4.2.x and trying to set the proxy callback URL on my client 
application.

First of all, I got an exception error message as below when trying to 
authenticate my sample web app.

HTTP Status 500 - org.jasig.cas.client.validation.TicketValidationException:

*type* Exception report

*message* *org.jasig.cas.client.validation.TicketValidationException:*

*description* *The server encountered an internal error that prevented it 
from fulfilling this request.*

*exception*

javax.servlet.ServletException: 
org.jasig.cas.client.validation.TicketValidationException: 
The supplied proxy callback url 
'https://acme.test.com:9443/mywebapp/proxyCallback 
' could not be 
authenticated.


org.jasig.cas.client.validation.AbstractTicketValidationFilter.doFilter(AbstractTicketValidationFilter.java:227)

org.jasig.cas.client.authentication.AuthenticationFilter.doFilter(AuthenticationFilter.java:164)

*root cause*

org.jasig.cas.client.validation.TicketValidationException: 
The supplied proxy callback url 
'https://acme.test.com:9443/mywebapp/proxyCallback 
' could not be 
authenticated.


org.jasig.cas.client.validation.Cas20ServiceTicketValidator.parseResponseFromServer(Cas20ServiceTicketValidator.java:84)

org.jasig.cas.client.validation.AbstractUrlBasedTicketValidator.validate(AbstractUrlBasedTicketValidator.java:201)

org.jasig.cas.client.validation.AbstractTicketValidationFilter.doFilter(AbstractTicketValidationFilter.java:204)

org.jasig.cas.client.authentication.AuthenticationFilter.doFilter(AuthenticationFilter.java:164)

*note* *The full stack trace of the root cause is available in the Apache 
Tomcat/8.0.26 logs.*
--
Apache Tomcat/8.0.26


For your reference, I set up some files such as cas-client.properties and 
web.xml of the sample web app, and a JSON file for the service registry as 
below.

*cas-client.properties*
casServerLoginUrl=http://accounts.test.com:8080/cas/login
serverName=https://acme.test.com:9443
casServerUrlPrefix=http://accounts.test.com:8080/cas/
gateway=false
proxyCallbackUrl=https://acme.test.com:9443/mywebapp/proxyCallback

*web.xml of the client application*


http://java.sun.com/xml/ns/j2ee; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee 
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;>
mywebapp

Simple sample, how to use CAS Java Client 3.x.
In this sample exists a public area (/)
and a private area (/protected/*). 






CAS Authentication Filter
org.jasig.cas.client.authentication.AuthenticationFilter



CAS Validation Filter
org.jasig.cas.client.validation.Cas30ProxyReceivingTicketValidationFilter



CAS HttpServletRequest Wrapper Filter
org.jasig.cas.client.util.HttpServletRequestWrapperFilter


CAS Assertion Thread Local Filter
org.jasig.cas.client.util.AssertionThreadLocalFilter








CAS Authentication Filter
/protected/*



CAS Validation Filter
/*

 

CAS HttpServletRequest Wrapper Filter
/*


CAS Assertion Thread Local Filter
/*


CAS Validation Filter
/proxyCallback 









index.jsp




*The JSON file of the service registry*
{
  "@class" : "org.jasig.cas.services.RegexRegisteredService",
  "serviceId" : "^https://.*.test.com.*;,
  "name" : "Test Web App",
  "theme" : "test",
  "id" : 175854194241240,
  "description" : "This is a web app for testing the theme change.",
  "proxyPolicy" : {
"@class" : 
"org.jasig.cas.services.RegexMatchingRegisteredServiceProxyPolicy",
"pattern" : "^https?://.*"
  },
  "evaluationOrder" : 0,
  "usernameAttributeProvider" : {
"@class" : 
"org.jasig.cas.services.DefaultRegisteredServiceUsernameProvider"
  },
  "logoutType" : "BACK_CHANNEL",
  "attributeReleasePolicy" : {
"@class" : "org.jasig.cas.services.ReturnAllAttributeReleasePolicy",
"authorizedToReleaseCredentialPassword" : false,
"authorizedToReleaseProxyGrantingTicket" : true
  },
  "accessStrategy" : {
"@class" : 
"org.jasig.cas.services.DefaultRegisteredServiceAccessStrategy",
"enabled" : true,
"ssoEnabled" : true
  }
}

As far as I understood, we just need to map a specific URL path with the 
CAS Validation Filter for the proxy callback URL, but looks like my 
assumption might not be right.

Can you anyone help me to understand how to set the proxy callback URL? 
Appreciated for your help in advance.

Thank you,
David

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit 

RE: [cas-user] question ldap auth ssl config upgrade 4.0.4 to 4.2

[Misagh Moayyed]

You add those as:



trustCertificates=""

trustStore=""

trustStorePassword="changeit"

trustStoreType="JKS"



along with other attributes.



From: cas-user@apereo.org [mailto:cas-user@apereo.org] On Behalf Of Nancy 
Snoke
Sent: Wednesday, April 13, 2016 12:29 PM
To: cas-user@apereo.org
Subject: [cas-user] question ldap auth ssl config upgrade 4.0.4 to 4.2



We had breaking changes on the upgrade and I was going through each feature 
one at a time for the upgrade.  Looking at the new ldap documentation I do 
not see how to add in ssl configuration (keystore, keystoreType, 
keystorePassword).  Do I need to continue to use the dozen beans I had 
previously to set up ssl configuration?



Current documentation shows using:



Previously  I had



   

  

   

 

Which does not fit in anywhere?



Any suggestions?



Thanks,

Nancy

-- 
You received this message because you are subscribed to the Google Groups 
"CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an 
email to cas-user+unsubscr...@apereo.org 
 .
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/9144c61058d840a08ade1c2bd0e201d7%40TGI-EX13BE03.pgac.com
 

 
.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/003f01d195e8%2477eac180%2467c04480%24%40unicon.net.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

[cas-user] Re: create a class in Cas server 4.0.1, receive credentials for authentication

[iris mc]

El miércoles, 13 de abril de 2016, 17:50:10 (UTC-5), iris mc escribió:
>
>
> Hello, I have a question, I need to add a Java class to cas version 4.0.1 
> project, I add a "java" folder inside the "main" folder, also I added a 
> class within the "java" folder.
> That class must extend and that method should I use to receive the 
> credentials (username and password)? I need to add logic to my class to 
> determine the source of search user ( in table or only in database schema)
>
   which is the moe for add a class and that it is recognized by the 
application? 

> then this class created injected into the next bean, my class  created is 
> ValidatorCas and id is dbAuthHandler
> Sorry, my english is little
>
>
>  class="org.jasig.cas.authentication.PolicyBasedAuthenticationManager">
> 
> 
>  value-ref="proxyPrincipalResolver" />
>
> value-ref="primaryPrincipalResolver"/>
> 
> 
>
> 
>  class="org.jasig.cas.authentication.AnyAuthenticationPolicy" />
> 
> 
>
>  
>
>
> class="org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler"
>   p:httpClient-ref="httpClient" />
>
>
> class="org.jasig.cas.authentication.principal.PersonDirectoryPrincipalResolver"
>  
> >
> 
> 
>
>
> Thanks
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/278855fe-b436-4dd6-a543-97ecdc01e085%40apereo.org.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

[cas-user] create a class in Cas server 4.0.1, receive credentials for authentication

[iris mc]

Hello, I have a question, I need to add a Java class to cas version 4.0.1 
project, I add a "java" folder inside the "main" folder, also I added a 
class within the "java" folder.
That class must extend and that method should I use to receive the 
credentials (username and password)? I need to add logic to my class to 
determine the source of search user ( in table or only in database schema)
then this class created injected into the next bean, my class  created is 
ValidatorCas and id is dbAuthHandler
Sorry, my english is little






   
   








 








Thanks

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/2386fc6e-b9ec-401f-9194-34ba7f4c8136%40apereo.org.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

[cas-user] question ldap auth ssl config upgrade 4.0.4 to 4.2

[Nancy Snoke]

We had breaking changes on the upgrade and I was going through each feature one 
at a time for the upgrade.  Looking at the new ldap documentation I do not see 
how to add in ssl configuration (keystore, keystoreType, keystorePassword).  Do 
I need to continue to use the dozen beans I had previously to set up ssl 
configuration?

Current documentation shows using:

Previously  I had

   
  
   
 
Which does not fit in anywhere?

Any suggestions?

Thanks,
Nancy

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/9144c61058d840a08ade1c2bd0e201d7%40TGI-EX13BE03.pgac.com.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

[cas-user] Limiting mapped Response results

[Dale]

Hello,

Is it possible to limit the responses a mapped result returns?

To clarify my intention

I have setup deployerConfigContext.xml with the following mappings..

 
==Truncated==

  










  


I have also 
setup "WEB-INF/view/jsp/protocol/2.0/casServiceValidationSuccess.jsp" with 
the following


 
  
${fn:escapeXml(assertion.chainedAuthentications[fn:length(assertion.chainedAuthentications)-1].principal.id)}
  

 
  
 
${fn:escapeXml(attr.value)}
   


   

This returns as expected for all mappings except for 
which returns an array of values [dsallis, 
dsallis_student, dsallis_admin]

Returning to my question, Can this return be limited to just the first 
result "dsallis"?

Thank you,
D.Sallis


-- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/be818a1b-1848-4105-9801-48d2132d9074%40apereo.org.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

RE: [cas-user] RE: CAS+Oauth

[Mahantesh Prasad Katti]

Thanks Jerome. Is it possible to have Classic CAS and Oauth CAS working at the 
same time? It’s possible that there are already some applications that are 
using CAS the conventional way. While newer applications may be working with 
Oauth based CAS. Is it possible for both to co-exist?

Regards,
Prasad

From: Jérôme LELEU [mailto:lel...@gmail.com]
Sent: Wednesday, April 13, 2016 3:38 PM
To: Mahantesh Prasad Katti
Cc: cas-user@apereo.org; Jaroslav Kacer
Subject: Re: [cas-user] RE: CAS+Oauth

Hi,

No, you'll get an access token once you access your application, though the 
value of the access token will be the TGT value and it will be the same for all 
OAuth clients. For CAS server < v4.2 only.

Best regards,
Jérôme


2016-04-13 11:32 GMT+02:00 Mahantesh Prasad Katti 
>:
Just so I get this right. Does this mean [in the oauth scenario] I will have to 
get an access token for each request that I make in my application?

Regards
Prasad

From: cas-user@apereo.org 
[mailto:cas-user@apereo.org] On Behalf Of Jérôme 
LELEU
Sent: Wednesday, April 13, 2016 2:24 PM
To: Mahantesh Prasad Katti
Cc: cas-user@apereo.org; Jaroslav Kacer
Subject: Re: [cas-user] RE: CAS+Oauth

Hi,

In fact, JWT is supported but not in OAuth support: JWT can be passed as token 
request parameter on the /login endpoint, assuming you have the appropriate 
configuration.

Before CAS 4.2, the access token was the TGT so it didn't take into account the 
service.
Since CAS 4.2, the service is taken into account.

Thanks.
Best regards,
Jérôme


2016-04-13 10:44 GMT+02:00 Mahantesh Prasad Katti 
>:
Yes. jwt can carry lot of information that can lead to federated authorization. 
BTW, I did see that JWT is supported [at least that is what I inferred.] based 
on the link 
http://jasig.github.io/cas/4.2.x/installation/JWT-Authentication.html. Please 
correct me if I am wrong.

I have another question on the opaque token currently supported. From my 
understanding, the service ticket [classic CAS]is specific to each URL. 
However, I believe it is not so for the oauth token. So if I have a portal, and 
I have a oauth token, I can the use the token while accessing all the 
URLs/links on the portal and not generate a token for each request I generate 
from the portal UI. Is that a correct understanding? Essentially, what I am 
hinting at is moving away from session based authentication.

Regards,
Prasad

From: Jérôme LELEU [mailto:lele...@gmail.com]
Sent: Wednesday, April 13, 2016 11:43 AM
To: Mahantesh Prasad Katti
Cc: Jaroslav Kacer; cas-user@apereo.org
Subject: Re: [cas-user] RE: CAS+Oauth

Hi,

I'm convinced by JWT as well. You meant returning JWT as access tokens, right?

Thanks.
Best regards,
Jérôme


2016-04-13 4:40 GMT+02:00 Mahantesh Prasad Katti 
>:
With JWT, we can reduce the load on the auth servers and that provides a 
massive scale when it comes to web applications [read internet facing]. Plus it 
is stateless and lightweight. It throws open so many interesting design and 
architecture paradigms.

Regards,
Prasad

From: Jérôme LELEU [mailto:lel...@gmail.com]
Sent: Wednesday, April 13, 2016 5:15 AM
To: Mahantesh Prasad Katti
Cc: Jaroslav Kacer; cas-user@apereo.org
Subject: Re: [cas-user] RE: CAS+Oauth

Hi,

Indeed, it was not a priority, but it's the second time I have a question about 
it, so it can become one.

JWT is planned for OpenID Connect support only for now: what use case do you 
have in mind?

Thanks.
Best regards,
Jérôme




2016-04-12 16:04 GMT+02:00 Mahantesh Prasad Katti 
>:
“I don't think client credentials grant type is our first use case “ – Did you 
mean it is not a priority?

JWT would be great. Is it on the roadmap?

Regards
Prasad

From: cas-user@apereo.org 
[mailto:cas-user@apereo.org] On Behalf Of Jérôme 
LELEU
Sent: Tuesday, April 12, 2016 7:25 PM
To: Mahantesh Prasad Katti
Cc: Jaroslav Kacer; cas-user@apereo.org
Subject: Re: [cas-user] RE: CAS+Oauth

Hi,

4. As the CAS server was the resource server and the authorization server and 
the only exposed resource was the user profile, only the grant types involving 
users made sense, and especially the authorization code grant type. Then, we 
addressed a larger scope by implementing the implicit and resource owner 
password.
I don't think client credentials grant type is our first use case, but it could 
make sense in some scenarios. Feel free to open a Github issue...

5. No, only opaque strings are sent for now: did you expect some JWT?

[cas-user] mod_auth_cas

[Chris Cheltenham]

Hello,

We are using mod_auth_cas.
We used to use this location syntax for 1.0.9.x


  Authtype CAS
  require valid-user
  CASAuthNHeader CAS_USER


I upgraded to mod_auth_cas 1.1RC1 but apache doesn't like "CAS_USER"


mod_auth_cas 1.1rc1 is giving me the error
AUTHORIZATION REQUIED

Thank You;

Chris Cheltenham
cchelten...@swaintechs.com
SwainTechs
10 Walnut Grove Rd
Suite 110
Horsham, PA
19044

888-905-5767 / X407


-- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/CO1PR07MB9370687DEED2C0B17AB1FCDC4960%40CO1PR07MB937.namprd07.prod.outlook.com.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

[cas-user] 4.1.8 snapshot error, but works in 4.1.5 release

[Yan Zhou]

Hi,

I am using 4.1.8 snapshot CAS, because that is the only version that has 
fixed the "Identifier too long" bug in JPA Service Registry for Oracle.

But I run into this error when login to CAS, did anyone have the same 
problem?When I switch back to 4.1.5 release of CAS, it works fine (but 
obviously, I cannot use Server Registry in Oracle, but JSON instead.)

Any suggestions?  The error follow.  I wonder if I misconfigured something, 
but switching to 4.1.5 CAS works correctly.  

Can someone verify that I have deployerConfigContext.xml defined correctly, 
at the bottom of this email?  

Thx,



2016-04-12 17:13:43,997 DEBUG 
[org.jasig.cas.audit.spi.TicketOrCredentialPrincipalResolver] - 

2016-04-12 17:13:43,998 INFO 
[org.jasig.inspektr.audit.support.Slf4jLoggingAuditTrailManager] -  

2016-04-12 17:13:44,002 DEBUG 
[org.jasig.cas.web.flow.AuthenticationViaFormAction] - <'principal' cannot 
be null.

Check the correctness of @Audit annotation at the following audit point: 
execution(public abstract transient 
org.jasig.cas.authentication.Authentication org.jasig.cas.authenticatio

n.AuthenticationManager.authenticate(org.jasig.cas.authentication.Credential[]))

java.lang.IllegalArgumentException: 'principal' cannot be null.

Check the correctness of @Audit annotation at the following audit point: 
execution(public abstract transient 
org.jasig.cas.authentication.Authentication org.jasig.cas.authenticatio

n.AuthenticationManager.authenticate(org.jasig.cas.authentication.Credential[]))

at 
org.jasig.inspektr.audit.AuditActionContext.assertNotNull(AuditActionContext.java:80)

at 
org.jasig.inspektr.audit.AuditActionContext.(AuditActionContext.java:62)

at 
org.jasig.inspektr.audit.AuditTrailManagementAspect.executeAuditCode(AuditTrailManagementAspect.java:153)

at 
org.jasig.inspektr.audit.AuditTrailManagementAspect.handleAuditTrail(AuditTrailManagementAspect.java:141)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)

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:68)

at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:168)

at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)

at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)

at 
com.ryantenney.metrics.spring.AbstractMetricMethodInterceptor.invoke(AbstractMetricMethodInterceptor.java:62)

at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)




This is my customized deployerConfigContext.xml




http://www.springframework.org/schema/beans;

   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;

   xmlns:context="http://www.springframework.org/schema/context;

   xmlns:p="http://www.springframework.org/schema/p;

   xmlns:c="http://www.springframework.org/schema/c;

   xmlns:tx="http://www.springframework.org/schema/tx;

   xmlns:util="http://www.springframework.org/schema/util;

  xmlns:jee="http://www.springframework.org/schema/jee;

   xmlns:sec="http://www.springframework.org/schema/security;

   xmlns:jpa="http://www.springframework.org/schema/data/jpa;

   xmlns:aop="http://www.springframework.org/schema/aop;

   xsi:schemaLocation="http://www.springframework.org/schema/beans 
http://www.springframework.org/schema/beans/spring-beans.xsd

   http://www.springframework.org/schema/context 
http://www.springframework.org/schema/context/spring-context.xsd

   http://www.springframework.org/schema/tx 
http://www.springframework.org/schema/tx/spring-tx.xsd

   http://www.springframework.org/schema/aop 
http://www.springframework.org/schema/aop/spring-aop.xsd  

   http://www.springframework.org/schema/security 
http://www.springframework.org/schema/security/spring-security.xsd

  http://www.springframework.org/schema/jee 
http://www.springframework.org/schema/jee/spring-jee.xsd

   http://www.springframework.org/schema/util 
http://www.springframework.org/schema/util/spring-util.xsd

   http://www.springframework.org/schema/data/jpa 
http://www.springframework.org/schema/data/jpa/spring-jpa.xsd; >



















 

Re: [cas-user] Ticket Granting Ticket ID Null in Logout Flow

[robert . pepersack]

I also debugged TerminateSessionAction and the ticket granting ticket it 
retrieves is also null.

On Tuesday, April 12, 2016 at 8:06:06 AM UTC-4, Robert wrote:
>
> Hi,
>
> I'm trying to get the CAS Principal (the authenticated user) from the TGT 
> in the logout web flow.  So, I tried to get the authenticated user's TGT at 
> the beginning of the logout web flow (i.e. stateEntering of 
> terminateSessionAction) using a web flow listener.  I have tried getting 
> the TGT ID using WebUtils.getTicketGrantingTicketId(context) 
> and ticketGrantingTicketCookieGenerator.retrieveCookieValue(request), but 
> both method calls return null.  I looked at the cookies with 
> request.getCookies() and it returns just the JSESSIONID cookie, so it 
> appears that the TGT cookie has been destroyed.  But, when I get the 
> tickets 
> using centralAuthenticationService.getTickets(TruePredicate.truePredicate()), 
> I see that the TGT is still in the DefaultTicketRegistry 
> and ticketGrantingTicket.isExpired() returns false.  Is there another way 
> to get the TGT and CAS Principal when the user logs out?
>
> Thanks!
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "CAS Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to cas-user+unsubscr...@apereo.org.
> Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/
> .
> To view this discussion on the web visit 
> https://groups.google.com/a/apereo.org/d/msgid/cas-user/c21550e3-6b55-4dae-9c0a-84e16bcce861%40apereo.org
>  
> 
> .
> For more options, visit https://groups.google.com/a/apereo.org/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/a608157e-7f9f-4f26-9365-db487278ccfc%40googlegroups.com.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

Re: [cas-user] Ticket Granting Ticket ID Null in Logout Flow

[robert . pepersack]

I tried moving my code from the web flow listener to my own action, which I 
made the first action to execute before terminateSessionAction,  I got the 
same result as with the listener:  the ticket granting ticket ID is null in 
my Eclipse debugger.  Here is what my action does:

public Event init(final RequestContext context) {
String tgtId = WebUtils.getTicketGrantingTicketId(context);
if (tgtId == null) {
final HttpServletRequest request = 
WebUtils.getHttpServletRequest(context);
tgtId = 
this.ticketGrantingTicketCookieGenerator.retrieveCookieValue(request);
}
if (tgtId != null) {
// Do stuff with the tgtId

In cas-servlet.xml, I just passed in the ticket granting ticket cookie 
generator as a constructor argument.

Here is my action in logout-webflow.xml:

  


  

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/c0f5461d-25d0-47ae-b73d-a9031d10cf8d%40googlegroups.com.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

Re: [cas-user] RE: CAS+Oauth

[Jérôme LELEU]

Hi,

No, you'll get an access token once you access your application, though the
value of the access token will be the TGT value and it will be the same for
all OAuth clients. For CAS server < v4.2 only.

Best regards,
Jérôme


2016-04-13 11:32 GMT+02:00 Mahantesh Prasad Katti <
mahantesh.ka...@indecomm.net>:

> Just so I get this right. Does this mean [in the oauth scenario] I will
> have to get an access token for each request that I make in my application?
>
>
>
> Regards
>
> Prasad
>
>
>
> *From:* cas-user@apereo.org [mailto:cas-user@apereo.org] *On Behalf Of *Jérôme
> LELEU
> *Sent:* Wednesday, April 13, 2016 2:24 PM
> *To:* Mahantesh Prasad Katti
> *Cc:* cas-user@apereo.org; Jaroslav Kacer
> *Subject:* Re: [cas-user] RE: CAS+Oauth
>
>
>
> Hi,
>
>
>
> In fact, JWT is supported but not in OAuth support: JWT can be passed as
> token request parameter on the /login endpoint, assuming you have the
> appropriate configuration.
>
>
>
> Before CAS 4.2, the access token was the TGT so it didn't take into
> account the service.
>
> Since CAS 4.2, the service is taken into account.
>
>
>
> Thanks.
>
> Best regards,
>
> Jérôme
>
>
>
>
>
> 2016-04-13 10:44 GMT+02:00 Mahantesh Prasad Katti <
> mahantesh.ka...@indecomm.net>:
>
> Yes. jwt can carry lot of information that can lead to federated
> authorization. BTW, I did see that JWT is supported [at least that is what
> I inferred.] based on the link
> http://jasig.github.io/cas/4.2.x/installation/JWT-Authentication.html.
> Please correct me if I am wrong.
>
>
>
> I have another question on the opaque token currently supported. From my
> understanding, the service ticket [classic CAS]is specific to each URL.
> However, I believe it is not so for the oauth token. So if I have a portal,
> and I have a oauth token, I can the use the token while accessing all the
> URLs/links on the portal and not generate a token for each request I
> generate from the portal UI. Is that a correct understanding? Essentially,
> what I am hinting at is moving away from session based authentication.
>
>
>
> Regards,
>
> Prasad
>
>
>
> *From:* Jérôme LELEU [mailto:lele...@gmail.com]
> *Sent:* Wednesday, April 13, 2016 11:43 AM
> *To:* Mahantesh Prasad Katti
> *Cc:* Jaroslav Kacer; cas-user@apereo.org
> *Subject:* Re: [cas-user] RE: CAS+Oauth
>
>
>
> Hi,
>
>
>
> I'm convinced by JWT as well. You meant returning JWT as access tokens,
> right?
>
>
>
> Thanks.
>
> Best regards,
>
> Jérôme
>
>
>
>
>
> 2016-04-13 4:40 GMT+02:00 Mahantesh Prasad Katti <
> mahantesh.ka...@indecomm.net>:
>
> With JWT, we can reduce the load on the auth servers and that provides a
> massive scale when it comes to web applications [read internet facing].
> Plus it is stateless and lightweight. It throws open so many interesting
> design and architecture paradigms.
>
>
>
> Regards,
>
> Prasad
>
>
>
> *From:* Jérôme LELEU [mailto:lel...@gmail.com]
> *Sent:* Wednesday, April 13, 2016 5:15 AM
> *To:* Mahantesh Prasad Katti
> *Cc:* Jaroslav Kacer; cas-user@apereo.org
> *Subject:* Re: [cas-user] RE: CAS+Oauth
>
>
>
> Hi,
>
>
>
> Indeed, it was not a priority, but it's the second time I have a question
> about it, so it can become one.
>
>
>
> JWT is planned for OpenID Connect support only for now: what use case do
> you have in mind?
>
>
>
> Thanks.
>
> Best regards,
>
> Jérôme
>
>
>
>
>
>
>
>
>
> 2016-04-12 16:04 GMT+02:00 Mahantesh Prasad Katti <
> mahantesh.ka...@indecomm.net>:
>
> “I don't think client credentials grant type is our first use case “ – Did
> you mean it is not a priority?
>
>
>
> JWT would be great. Is it on the roadmap?
>
>
>
> Regards
>
> Prasad
>
>
>
> *From:* cas-user@apereo.org [mailto:cas-user@apereo.org] *On Behalf Of *Jérôme
> LELEU
> *Sent:* Tuesday, April 12, 2016 7:25 PM
> *To:* Mahantesh Prasad Katti
> *Cc:* Jaroslav Kacer; cas-user@apereo.org
> *Subject:* Re: [cas-user] RE: CAS+Oauth
>
>
>
> Hi,
>
>
>
> 4. As the CAS server was the resource server and the authorization server
> and the only exposed resource was the user profile, only the grant types
> involving users made sense, and especially the authorization code grant
> type. Then, we addressed a larger scope by implementing the implicit and
> resource owner password.
>
> I don't think client credentials grant type is our first use case, but it
> could make sense in some scenarios. Feel free to open a Github issue...
>
>
>
> 5. No, only opaque strings are sent for now: did you expect some JWT?
>
>
>
> Thanks.
>
> Best regards,
>
> Jérôme
>
>
>
>
>
> 2016-04-12 15:27 GMT+02:00 Mahantesh Prasad Katti <
> mahantesh.ka...@indecomm.net>:
>
> 4. we are building micro services based strategy. So if there is an
> interaction between two services that is non-human, service A would get an
> access token by providing the client_id and secret and invoke the service B
> by sending the bearer token. Client Credential Grant type is a standard
> oauth grant type. Is there any reason why it would not be supported?
>
>
>
> 5. Also, is there a way we can 

RE: [cas-user] RE: CAS+Oauth

[Mahantesh Prasad Katti]

Just so I get this right. Does this mean [in the oauth scenario] I will have to 
get an access token for each request that I make in my application?

Regards
Prasad

From: cas-user@apereo.org [mailto:cas-user@apereo.org] On Behalf Of Jérôme LELEU
Sent: Wednesday, April 13, 2016 2:24 PM
To: Mahantesh Prasad Katti
Cc: cas-user@apereo.org; Jaroslav Kacer
Subject: Re: [cas-user] RE: CAS+Oauth

Hi,

In fact, JWT is supported but not in OAuth support: JWT can be passed as token 
request parameter on the /login endpoint, assuming you have the appropriate 
configuration.

Before CAS 4.2, the access token was the TGT so it didn't take into account the 
service.
Since CAS 4.2, the service is taken into account.

Thanks.
Best regards,
Jérôme


2016-04-13 10:44 GMT+02:00 Mahantesh Prasad Katti 
>:
Yes. jwt can carry lot of information that can lead to federated authorization. 
BTW, I did see that JWT is supported [at least that is what I inferred.] based 
on the link 
http://jasig.github.io/cas/4.2.x/installation/JWT-Authentication.html. Please 
correct me if I am wrong.

I have another question on the opaque token currently supported. From my 
understanding, the service ticket [classic CAS]is specific to each URL. 
However, I believe it is not so for the oauth token. So if I have a portal, and 
I have a oauth token, I can the use the token while accessing all the 
URLs/links on the portal and not generate a token for each request I generate 
from the portal UI. Is that a correct understanding? Essentially, what I am 
hinting at is moving away from session based authentication.

Regards,
Prasad

From: Jérôme LELEU [mailto:lele...@gmail.com]
Sent: Wednesday, April 13, 2016 11:43 AM
To: Mahantesh Prasad Katti
Cc: Jaroslav Kacer; cas-user@apereo.org
Subject: Re: [cas-user] RE: CAS+Oauth

Hi,

I'm convinced by JWT as well. You meant returning JWT as access tokens, right?

Thanks.
Best regards,
Jérôme


2016-04-13 4:40 GMT+02:00 Mahantesh Prasad Katti 
>:
With JWT, we can reduce the load on the auth servers and that provides a 
massive scale when it comes to web applications [read internet facing]. Plus it 
is stateless and lightweight. It throws open so many interesting design and 
architecture paradigms.

Regards,
Prasad

From: Jérôme LELEU [mailto:lel...@gmail.com]
Sent: Wednesday, April 13, 2016 5:15 AM
To: Mahantesh Prasad Katti
Cc: Jaroslav Kacer; cas-user@apereo.org
Subject: Re: [cas-user] RE: CAS+Oauth

Hi,

Indeed, it was not a priority, but it's the second time I have a question about 
it, so it can become one.

JWT is planned for OpenID Connect support only for now: what use case do you 
have in mind?

Thanks.
Best regards,
Jérôme




2016-04-12 16:04 GMT+02:00 Mahantesh Prasad Katti 
>:
“I don't think client credentials grant type is our first use case “ – Did you 
mean it is not a priority?

JWT would be great. Is it on the roadmap?

Regards
Prasad

From: cas-user@apereo.org 
[mailto:cas-user@apereo.org] On Behalf Of Jérôme 
LELEU
Sent: Tuesday, April 12, 2016 7:25 PM
To: Mahantesh Prasad Katti
Cc: Jaroslav Kacer; cas-user@apereo.org
Subject: Re: [cas-user] RE: CAS+Oauth

Hi,

4. As the CAS server was the resource server and the authorization server and 
the only exposed resource was the user profile, only the grant types involving 
users made sense, and especially the authorization code grant type. Then, we 
addressed a larger scope by implementing the implicit and resource owner 
password.
I don't think client credentials grant type is our first use case, but it could 
make sense in some scenarios. Feel free to open a Github issue...

5. No, only opaque strings are sent for now: did you expect some JWT?

Thanks.
Best regards,
Jérôme


2016-04-12 15:27 GMT+02:00 Mahantesh Prasad Katti 
>:
4. we are building micro services based strategy. So if there is an interaction 
between two services that is non-human, service A would get an access token by 
providing the client_id and secret and invoke the service B by sending the 
bearer token. Client Credential Grant type is a standard oauth grant type. Is 
there any reason why it would not be supported?

5. Also, is there a way we can configure what kind of tokens get sent? Right 
now the tokens that get sent are opaque that need to be validated with the CAS 
server.

Thanks for sharing information.

Regards,
Prasad Katti

From: Jérôme LELEU [mailto:lel...@gmail.com]
Sent: Tuesday, April 12, 2016 6:08 PM
To: Jaroslav Kacer
Cc: Mahantesh Prasad Katti; 

Re: [cas-user] RE: CAS+Oauth

[Jérôme LELEU]

Hi,

In fact, JWT is supported but not in OAuth support: JWT can be passed as
token request parameter on the /login endpoint, assuming you have the
appropriate configuration.

Before CAS 4.2, the access token was the TGT so it didn't take into account
the service.
Since CAS 4.2, the service is taken into account.

Thanks.
Best regards,
Jérôme


2016-04-13 10:44 GMT+02:00 Mahantesh Prasad Katti <
mahantesh.ka...@indecomm.net>:

> Yes. jwt can carry lot of information that can lead to federated
> authorization. BTW, I did see that JWT is supported [at least that is what
> I inferred.] based on the link
> http://jasig.github.io/cas/4.2.x/installation/JWT-Authentication.html.
> Please correct me if I am wrong.
>
>
>
> I have another question on the opaque token currently supported. From my
> understanding, the service ticket [classic CAS]is specific to each URL.
> However, I believe it is not so for the oauth token. So if I have a portal,
> and I have a oauth token, I can the use the token while accessing all the
> URLs/links on the portal and not generate a token for each request I
> generate from the portal UI. Is that a correct understanding? Essentially,
> what I am hinting at is moving away from session based authentication.
>
>
>
> Regards,
>
> Prasad
>
>
>
> *From:* Jérôme LELEU [mailto:lele...@gmail.com]
> *Sent:* Wednesday, April 13, 2016 11:43 AM
> *To:* Mahantesh Prasad Katti
> *Cc:* Jaroslav Kacer; cas-user@apereo.org
> *Subject:* Re: [cas-user] RE: CAS+Oauth
>
>
>
> Hi,
>
>
>
> I'm convinced by JWT as well. You meant returning JWT as access tokens,
> right?
>
>
>
> Thanks.
>
> Best regards,
>
> Jérôme
>
>
>
>
>
> 2016-04-13 4:40 GMT+02:00 Mahantesh Prasad Katti <
> mahantesh.ka...@indecomm.net>:
>
> With JWT, we can reduce the load on the auth servers and that provides a
> massive scale when it comes to web applications [read internet facing].
> Plus it is stateless and lightweight. It throws open so many interesting
> design and architecture paradigms.
>
>
>
> Regards,
>
> Prasad
>
>
>
> *From:* Jérôme LELEU [mailto:lel...@gmail.com]
> *Sent:* Wednesday, April 13, 2016 5:15 AM
> *To:* Mahantesh Prasad Katti
> *Cc:* Jaroslav Kacer; cas-user@apereo.org
> *Subject:* Re: [cas-user] RE: CAS+Oauth
>
>
>
> Hi,
>
>
>
> Indeed, it was not a priority, but it's the second time I have a question
> about it, so it can become one.
>
>
>
> JWT is planned for OpenID Connect support only for now: what use case do
> you have in mind?
>
>
>
> Thanks.
>
> Best regards,
>
> Jérôme
>
>
>
>
>
>
>
>
>
> 2016-04-12 16:04 GMT+02:00 Mahantesh Prasad Katti <
> mahantesh.ka...@indecomm.net>:
>
> “I don't think client credentials grant type is our first use case “ – Did
> you mean it is not a priority?
>
>
>
> JWT would be great. Is it on the roadmap?
>
>
>
> Regards
>
> Prasad
>
>
>
> *From:* cas-user@apereo.org [mailto:cas-user@apereo.org] *On Behalf Of *Jérôme
> LELEU
> *Sent:* Tuesday, April 12, 2016 7:25 PM
> *To:* Mahantesh Prasad Katti
> *Cc:* Jaroslav Kacer; cas-user@apereo.org
> *Subject:* Re: [cas-user] RE: CAS+Oauth
>
>
>
> Hi,
>
>
>
> 4. As the CAS server was the resource server and the authorization server
> and the only exposed resource was the user profile, only the grant types
> involving users made sense, and especially the authorization code grant
> type. Then, we addressed a larger scope by implementing the implicit and
> resource owner password.
>
> I don't think client credentials grant type is our first use case, but it
> could make sense in some scenarios. Feel free to open a Github issue...
>
>
>
> 5. No, only opaque strings are sent for now: did you expect some JWT?
>
>
>
> Thanks.
>
> Best regards,
>
> Jérôme
>
>
>
>
>
> 2016-04-12 15:27 GMT+02:00 Mahantesh Prasad Katti <
> mahantesh.ka...@indecomm.net>:
>
> 4. we are building micro services based strategy. So if there is an
> interaction between two services that is non-human, service A would get an
> access token by providing the client_id and secret and invoke the service B
> by sending the bearer token. Client Credential Grant type is a standard
> oauth grant type. Is there any reason why it would not be supported?
>
>
>
> 5. Also, is there a way we can configure what kind of tokens get sent?
> Right now the tokens that get sent are opaque that need to be validated
> with the CAS server.
>
>
>
> Thanks for sharing information.
>
>
>
> Regards,
>
> Prasad Katti
>
>
>
> *From:* Jérôme LELEU [mailto:lel...@gmail.com]
> *Sent:* Tuesday, April 12, 2016 6:08 PM
> *To:* Jaroslav Kacer
> *Cc:* Mahantesh Prasad Katti; cas-user@apereo.org
> *Subject:* Re: [cas-user] RE: CAS+Oauth
>
>
>
> Hi,
>
>
>
> 1. 2. Correct. We currently only support the authorization code grant
> type. Version 5.0.0 of CAS (in development) will support the implicit,
> resource password credentials and refresh tokens grant types. You can
> already test them.
>
> Until the release, you are on your own and developing these new grant
> types is not easy.
>
>
>
> 3. Before CAS server 

RE: [cas-user] RE: CAS+Oauth

[Mahantesh Prasad Katti]

Yes. jwt can carry lot of information that can lead to federated authorization. 
BTW, I did see that JWT is supported [at least that is what I inferred.] based 
on the link 
http://jasig.github.io/cas/4.2.x/installation/JWT-Authentication.html. Please 
correct me if I am wrong.

I have another question on the opaque token currently supported. From my 
understanding, the service ticket [classic CAS]is specific to each URL. 
However, I believe it is not so for the oauth token. So if I have a portal, and 
I have a oauth token, I can the use the token while accessing all the 
URLs/links on the portal and not generate a token for each request I generate 
from the portal UI. Is that a correct understanding? Essentially, what I am 
hinting at is moving away from session based authentication.

Regards,
Prasad

From: Jérôme LELEU [mailto:lele...@gmail.com]
Sent: Wednesday, April 13, 2016 11:43 AM
To: Mahantesh Prasad Katti
Cc: Jaroslav Kacer; cas-user@apereo.org
Subject: Re: [cas-user] RE: CAS+Oauth

Hi,

I'm convinced by JWT as well. You meant returning JWT as access tokens, right?

Thanks.
Best regards,
Jérôme


2016-04-13 4:40 GMT+02:00 Mahantesh Prasad Katti 
>:
With JWT, we can reduce the load on the auth servers and that provides a 
massive scale when it comes to web applications [read internet facing]. Plus it 
is stateless and lightweight. It throws open so many interesting design and 
architecture paradigms.

Regards,
Prasad

From: Jérôme LELEU [mailto:lel...@gmail.com]
Sent: Wednesday, April 13, 2016 5:15 AM
To: Mahantesh Prasad Katti
Cc: Jaroslav Kacer; cas-user@apereo.org
Subject: Re: [cas-user] RE: CAS+Oauth

Hi,

Indeed, it was not a priority, but it's the second time I have a question about 
it, so it can become one.

JWT is planned for OpenID Connect support only for now: what use case do you 
have in mind?

Thanks.
Best regards,
Jérôme




2016-04-12 16:04 GMT+02:00 Mahantesh Prasad Katti 
>:
“I don't think client credentials grant type is our first use case “ – Did you 
mean it is not a priority?

JWT would be great. Is it on the roadmap?

Regards
Prasad

From: cas-user@apereo.org 
[mailto:cas-user@apereo.org] On Behalf Of Jérôme 
LELEU
Sent: Tuesday, April 12, 2016 7:25 PM
To: Mahantesh Prasad Katti
Cc: Jaroslav Kacer; cas-user@apereo.org
Subject: Re: [cas-user] RE: CAS+Oauth

Hi,

4. As the CAS server was the resource server and the authorization server and 
the only exposed resource was the user profile, only the grant types involving 
users made sense, and especially the authorization code grant type. Then, we 
addressed a larger scope by implementing the implicit and resource owner 
password.
I don't think client credentials grant type is our first use case, but it could 
make sense in some scenarios. Feel free to open a Github issue...

5. No, only opaque strings are sent for now: did you expect some JWT?

Thanks.
Best regards,
Jérôme


2016-04-12 15:27 GMT+02:00 Mahantesh Prasad Katti 
>:
4. we are building micro services based strategy. So if there is an interaction 
between two services that is non-human, service A would get an access token by 
providing the client_id and secret and invoke the service B by sending the 
bearer token. Client Credential Grant type is a standard oauth grant type. Is 
there any reason why it would not be supported?

5. Also, is there a way we can configure what kind of tokens get sent? Right 
now the tokens that get sent are opaque that need to be validated with the CAS 
server.

Thanks for sharing information.

Regards,
Prasad Katti

From: Jérôme LELEU [mailto:lel...@gmail.com]
Sent: Tuesday, April 12, 2016 6:08 PM
To: Jaroslav Kacer
Cc: Mahantesh Prasad Katti; cas-user@apereo.org
Subject: Re: [cas-user] RE: CAS+Oauth

Hi,

1. 2. Correct. We currently only support the authorization code grant type. 
Version 5.0.0 of CAS (in development) will support the implicit, resource 
password credentials and refresh tokens grant types. You can already test them.
Until the release, you are on your own and developing these new grant types is 
not easy.

3. Before CAS server 4.2, the /profile endpoint returns all attributes, since 
CAS 4.2, the returned attributes are the ones defined by the services like for 
any CAS service.

4. The cas-management-webapp in the latest CAS versions allows you to register 
the OAuth clients. Before, you had to add them manually. The client credentials 
grant type is not supported and won't be: I'm not sure to understand what could 
be your use case.

5. The OAuth server redirects (302 HTTP) to the CAS server for login. The OAuth 
client from pac4j 

[cas-user] Re: Proxy Granting Tickets

[David Lee]

One more thing is...when I try to check whether the ticket is valid on the 
URL /cas/serviceValidate it always returns INVALID_TICKET.
But the ticket is same to the one returned to the CAS client app and so is 
the service URL.

I guess it's because the ticket returned from CAS is just for one time, and 
it should be PGT. I'm guessing like so.

Can anyone tell me if my assumption is right or not?

On Wednesday, April 13, 2016 at 4:44:09 PM UTC+9, David Lee wrote:
>
> Hi,
>
> We're using CAS 4.2 and are considering Proxy Granting Tickets since we 
> have a separated app providing APIs and it needs to authenticate requests 
> prior to sending requests to the APIs.
>
> followed some instructions suggested on the documents we found by 
> googling, but looks like something have been updated since the documents 
> were written.
>
> As far as understood it needs to add something to the file 
> deployerConfContext.xml to use PGT but couldn't find how to do that in CAS 
> 4.2.
> Appreciated if anyone helps me to understand about what to do in the 
> deployerConfContext.xml of CAS 4.2 for PGT.
>
> Another question is that we've figured out the client app needs to set the 
> proxyCallbackUrl to use PGT, how should we implement the proxyCallbackUrl 
> on the CAS client app?
>
> Appreciated if anyone shares something about the PGT on CAS 4.2 with me.
>
> Thank you in advance!
>
> David
>
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cas-user+unsubscr...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/03dd7475-b77b-4a19-ad1c-0f7f5e72bf4c%40apereo.org.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.