date:20200601

Re: [cas-user] cas.ticket.tgt.timeout.maxTimeToLiveInSeconds and Memcache ticket experation policy

2020-06-01 Thread Ray Bon

John,

Timeout has higher priority than Default.
timeout.maxTimeToLiveInSeconds is a more general approach (an application like 
an webmail client, that hits cas every 10m when it checks for new mail, will 
keep the TGT alive while the tab is open).

The two settings in Default, maxTimeToLiveInSeconds and timeToKillInSeconds, 
provide for the timeout sliding window but have a hard stop at 
maxTimeToLiveInSeconds. (With this approach, webmail app will require a new log 
in after maxTimeToLiveInSeconds.)

In my previous response, I incorrectly stated the behaviour.

https://apereo.github.io/cas/6.1.x/configuration/Configuration-Properties.html#tgt-expiration-policy
says that to disable a policy, set its value to 0 or less.
Maybe by setting timeout.maxTimeToLiveInSeconds, it forces 
maxTimeToLiveInSeconds to -1 and this value gets sent to memcache.

The similarly named fields are quite confusing (I got caught this morning). 
Perhaps it would be clearer if timeout.maxTimeToLiveInSeconds and 
timeToKillInSeconds where named sessionTimeToLiveInSeconds, since they refer to 
the length of time the session will live after the last time the TGT was used.

Ray

On Mon, 2020-06-01 at 18:35 +0200, John Bond wrote:
Hi Ray,

Thanks for the response however ...

On Mon, Jun 1, 2020 at 6:16 PM Ray Bon mailto:r...@uvic.ca>> 
wrote:
John,

https://apereo.github.io/cas/6.1.x/ticketing/Configuring-Ticket-Expiration-Policy.html

timeout.maxTimeToLive... is a hard timeout. The other is a 'must be used within 
this time' to be valid. If the TGT is used within this window, the validity 
will extend by that time up to timeout.maxTimeToLive...
View Task


I thought that was the difference between cas.ticket.tgt.maxTimeToLiveInSeconds 
and cas.ticket.tgt.maxTimeToLiveInSeconds i.e.

  * cas.ticket.tgt.timeToKillInSeconds
- If cas has seen no access from a user in this time kill the ticket
   * cas.ticket.tgt.maxTimeToLiveInSeconds
- Regardless of anything always kill the ticket after this timeout
  * cas.ticket.tgt.timeout.maxTimeToLiveInSeconds
- ???

If not what does cas.ticket.tgt.timeToKillInSeconds control?

Thanks

--

Ray Bon
Programmer Analyst
Development Services, University Systems
2507218831 | CLE 019 | r...@uvic.ca

I respectfully acknowledge that my place of work is located within the 
ancestral, traditional and unceded territory of the Songhees, Esquimalt and 
WSÁNEĆ Nations.

-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
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.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/4d67023b25aac96a9dd0037adcb133b5e548ae7c.camel%40uvic.ca.

Re: [cas-user] CAS 6 Attribute Release

2020-06-01 Thread Bryan Wooten

I added those log settings...

We also tried changing our gradle.properties from SNAPSHOT to RC5 and that
just broke the Duo login flow...

I added this to cas.properties: #Attribute Release

cas.authn.authenticationAttributeRelease.enabled=true

And I also change the JSON service registry to:"attributeReleasePolicy" : {
   "@class" : "org.apereo.cas.services.ReturnAllAttributeReleasePolicy"
  }

Still no luck

On Mon, Jun 1, 2020 at 10:06 AM Ray Bon  wrote:

> Bryan,
>
> Maybe these loggers can help.
>  
> 
>  name="org.apereo.cas.services.AbstractRegisteredServiceAttributeReleasePolicy"
> level="warn"/>
>
> 
>  name="org.apereo.cas.services.DenyAllAttributeReleasePolicy" level="warn"/>
>
> Ray
>
> On Mon, 2020-06-01 at 08:34 -0600, Bryan Wooten wrote:
>
> We are doing a POC with CAS 6. We are building using the war overlay. Are
> build is from the CAS 6 Master branch.
>
> I have a simple Java client app configured for SAML1.1. This app is
> running on the same Tomcat as CAS 6 itself. This is its JSON service
> registry entry:
>
> {
>   "@class" : "org.apereo.cas.services.RegexRegisteredService",
>   "serviceId" : "^https://cas6test.go.utah.edu/.*;,
>   "name" : "cas6dev-1IdmUtahEdu",
>   "id" : 2020052801,
>   "description" : "bryan.woo...@utah.edu",
>   "logoutType" : "FRONT_CHANNEL",
>"attributeReleasePolicy" : {
> "@class" :
> "org.jasig.cas.services.ReturnAllowedAttributeReleasePolicy",
> "allowedAttributes" : [ "java.util.ArrayList", [ "firstName",
> "lastName", "displayName", "email", "homephone", "department", "ou", "cn",
> "telephoneNumber", "acadplan", "almail", "eduPersonAffiliation", "uid",
> "eduPersonPrincipalName", "ummail", "unid", "uudept", "uuemployee",
> "uustudent","psrole" ] ]
>   }
> }
>
> In the cas.log I see:
> allowedAttributes=[firstName, lastName, displayName, email, homephone,
> department, ou, cn, telephoneNumber, acadplan, almail,
> eduPersonAffiliation, uid, eduPersonPrincipalName, ummail, unid, uudept,
> uuemployee, uustudent, psrole]),
> multifactorPolicy=DefaultRegisteredServiceMultifactorPolicy(multifactorAuthenticationProviders=[],
> failureMode=UNDEFINED, principalAttributeNameTrigger=null,
> principalAttributeValueToMatch=null, bypassEnabled=false,
> forceExecution=false, bypassTrustedDeviceEnabled=false, bypassPrincipa
>
> That looks good.
>
> But when the SAML assertion is built it doesn't include those attribute:
>
> Any ideas on what I am missing?
>
> 
> http://schemas.xmlsoap.org/soap/envelope/;>
> 
>  InResponseTo="_0f257af65322193bce619eb2d16895e7"
> IssueInstant="2020-06-01T13:54:43.797Z" MajorVersion="1"
> MinorVersion="1"
> ResponseID="_07a0fc4799c4445d58e12d00aa84603b"
> xmlns:saml1p="urn:oasis:names:tc:SAML:1.0:protocol">
> 
> 
> 
>  AssertionID="_c4f37a7ef71853b1fb8e472d6db12faf"
> IssueInstant="2020-06-01T13:54:43.797Z"
> Issuer="localhost" MajorVersion="1" MinorVersion="1"
> xmlns:saml1="urn:oasis:names:tc:SAML:1.0:assertion">
>  NotOnOrAfter="2020-06-01T13:55:13.797Z">
> 
> 
> https://cas6test.go.utah.edu/attrrelease-1.0-SNAPSHOT/attrrelease
> 
> 
> 
>  AuthenticationInstant="2020-06-01T13:54:48.138Z"
> AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:passwor
> d">
> 
>
> u0519980
> 
>
> 
> 
> 
> 
> 
>
> u0519980
> 
>
> urn:oasis:names:tc:SAML:1.0:cm:artifact
> 
> 
>  AttributeNamespace="http://www.ja-sig.org/products/cas/;>
>
> UsernamePasswordCredential
>
> DuoSecurityCredential
> 
> 
> AttributeName="samlAuthenticationStatementAuthMethod" AttributeNamespace="
> http://www.ja-sig.org/products/cas/;>
>
> urn:oasis:names:tc:SAML:1.0:am:password
>
> urn:oasis:names:tc:SAML:1.0:am:unspecified
> 
>  AttributeNamespace="http://www.ja-sig.org/products/cas/;>
>
> u0519980
> 
>  AttributeNamespace="http://www.ja-sig.org/products/cas/;>
> true
> 
>  AttributeName="bypassMultifactorAuthentication"
> AttributeNamespace="http://www.ja-sig.org/products/cas/;>
> false
> 
>  AttributeNamespace="http://www.ja-sig.org/products/cas/;>
>
> 2020-06-01T13:54:48.138360Z
> 
>   AttributeNamespace="http://www.ja-sig.org/products/cas/;>
> true
> 
>

[cas-user] CAS 6.1.6 inotify instances skyrocketing with Groovy files in SAML service.

2020-06-01 Thread William Jojo

Been running 6.1.6 for about 2 weeks. No issues - until I added SAML 
support. This morning I noticed CAS no longer working. Checked log and 
found:

>From log:

2020-06-01 09:05:32,086 INFO [org.apereo.cas.util.io.PathWatcherService] - 
<*Watching 
directory at [/etc/cas/saml]*>
2020-06-01 09:05:32,086 ERROR 
[org.apereo.cas.services.ReturnMappedAttributeReleasePolicy] - <*User limit 
of inotify instances reached or too many open files*>
java.io.IOException: *User limit of inotify instances reached or too many 
open files*
at sun.nio.fs.LinuxWatchService.(LinuxWatchService.java:64) ~[?:?]
at sun.nio.fs.LinuxFileSystem.newWatchService(LinuxFileSystem.java:47) 
~[?:?]
at 
org.apereo.cas.util.io.PathWatcherService.(PathWatcherService.java:62) 
~[cas-server-core-util-api-6.1.6.jar:6.1.6]
at 
org.apereo.cas.util.io.PathWatcherService.(PathWatcherService.java:40) 
~[cas-server-core-util-api-6.1.6.jar:6.1.6]
at 
org.apereo.cas.util.io.FileWatcherService.(FileWatcherService.java:26) 
~[cas-server-core-util-api-6.1.6.jar:6.1.6]
at 
org.apereo.cas.util.scripting.*WatchableGroovyScriptResource*.(WatchableGroovyScriptResource.java:31)
 
~[cas-server-core-util-api-6.1.6.jar:6.1.6]


Thought this was odd since never had this problem with any other area of 
CAS watch areas. Did some digging and seems this is NOT an issue UNTIL I 
added the groovy files to a SAML service.

The portion of the JSON is as follows:

  memberOf:
  [
java.util.ArrayList
[
file:/etc/cas/saml/memberOf.groovy
]
  ]
  eduPersonPrimaryAffiliation:
  [
java.util.ArrayList
[
file:/etc/cas/saml/eduPersonPrimaryAffiliation.groovy
]
  ]

Now look at this output:

root@casdev-master:~# while (( 1 == 1 )); do date; lsof | grep inotify | 
grep 31744 | wc -l; sleep 120; done

Mon Jun  1 11:28:05 EDT 2020

178

Mon Jun  1 11:30:05 EDT 2020

178

Mon Jun  1 11:32:06 EDT 2020

178

Mon Jun  1 11:34:06 EDT 2020

178

Mon Jun  1 11:36:07 EDT 2020

178

Mon Jun  1 11:38:08 EDT 2020

178

Mon Jun  1 11:40:08 EDT 2020

1872

Mon Jun  1 11:42:09 EDT 2020

2500

Mon Jun  1 11:44:10 EDT 2020

3192

Mon Jun  1 11:46:11 EDT 2020

3948

Mon Jun  1 11:48:12 EDT 2020

4768

Mon Jun  1 11:50:13 EDT 2020

5652

Mon Jun  1 11:52:14 EDT 2020

6600

There are 178 inotify watches consistently UNTIL I edit the service file 
and allow the Groovy files to be used. Then it just goes out of control. 
There were this many entries for each:

root@casdev-master:~# lsof | grep inotify | grep 31744 | grep edu | wc -l
1200
root@casdev-master:~# lsof | grep inotify | grep 31744 | grep member | wc -l
1104

It seems too be increasing by hundreds of entries per TID in a very brief 
period of time and it also seems to be affecting other inotify counts as a 
result. Any thoughts on why this would suddenly go out of control when 
adding Groovy files to the service?

Thank you!

Bill

-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
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.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/cabd1c8b-8a15-4932-b618-5e17b1188f59%40apereo.org.

Re: [cas-user] cas.ticket.tgt.timeout.maxTimeToLiveInSeconds and Memcache ticket experation policy

2020-06-01 Thread John Bond

Hi Ray,

Thanks for the response however ...

On Mon, Jun 1, 2020 at 6:16 PM Ray Bon  wrote:

> John,
>
>
> https://apereo.github.io/cas/6.1.x/ticketing/Configuring-Ticket-Expiration-Policy.html
>
> timeout.maxTimeToLive... is a hard timeout. The other is a 'must be used
> within this time' to be valid. If the TGT is used within this window, the
> validity will extend by that time up to timeout.maxTimeToLive...
> View Task 
>

I thought that was the difference between cas.ticket.tgt.maxTimeToLiveInSeconds
and cas.ticket.tgt.maxTimeToLiveInSeconds i.e.

  * cas.ticket.tgt.timeToKillInSeconds
- If cas has seen no access from a user in this time kill the ticket
   * cas.ticket.tgt.maxTimeToLiveInSeconds
- Regardless of anything always kill the ticket after this timeout
  * cas.ticket.tgt.timeout.maxTimeToLiveInSeconds
- ???

If not what does cas.ticket.tgt.timeToKillInSeconds control?

Thanks

-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
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.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAA7%2BHnAn3TuWLCmQjKMJchukwK2bQHw312f9nV%2BUN2ZAtTkpiA%40mail.gmail.com.

Re: [cas-user] cas.ticket.tgt.timeout.maxTimeToLiveInSeconds and Memcache ticket experation policy

2020-06-01 Thread Ray Bon

John,

https://apereo.github.io/cas/6.1.x/ticketing/Configuring-Ticket-Expiration-Policy.html

timeout.maxTimeToLive... is a hard timeout. The other is a 'must be used within 
this time' to be valid. If the TGT is used within this window, the validity 
will extend by that time up to timeout.maxTimeToLive...

Ray

On Mon, 2020-06-01 at 08:09 -0700, John Bond wrote:
Hello All,

In out config we set both cas.ticket.tgt.timeout.maxTimeToLiveInSeconds and 
cas.ticket.tgt.maxTimeToLiveInSeconds to the same value believing theses where 
the same and  made a note to validate this with this group[1]. That later step 
never happened and the config remained.  however today i tried to implement 
memcache as the ticket store and i noticed via tcpdump that CAS was setting the 
memcache value with an expiry time of -1, this effectively means don't cache so 
when CAS tries to fetch the ticket it doesn't exist.   Checking my logs i 
notice the following debug messages which seemed confusing


2020-06-01 14 05 44,597 DEBUG 
[org.apereo.cas.ticket.expiration.builder.TicketGrantingTicketExpirationPolicyBuilder]
 - 
2020-06-01 14 05 44,599 DEBUG 
[org.apereo.cas.ticket.expiration.builder.TicketGrantingTicketExpirationPolicyBuilder]
 - 

memcache only supports an int for the expiry however the final value we have is 
9223372036854775807, my assumption is that this at some point this gets 
coalesced down to -1.  however i'm curious why the final value is not 604800.

Looking at the code i see that when setting  
`cas.ticket.tgt.timeout.maxTimeToLiveInSeconds` the final timeout value comes 
from TimeoutExpirationPolicy.java which always returns Long.MAX_VALUE[1].  When 
setting only `cas.ticket.tgt.maxTimeToLiveInSeconds`  the timeout value comes 
from TicketGrantingTicketExpirationPolicy.java which returns 
`this.maxTimeToLiveInSeconds` which is the value i would expect.  The logic 
that makes this choice is in TicketGrantingTicketExpirationPolicyBuilder.java

With this in mind could someone explain the difference between the two config 
items or point me to further documentation.  Further it seems that the use of 
cas.ticket.tgt.timeout.maxTimeToLiveInSeconds is not currently compatible with 
memcache.

We are running CAS 6.5.1 on debian buster, let me know if further information 
is required.

Thanks


[1]https://github.com/apereo/cas/blob/v6.1.5/core/cas-server-core-tickets-api/src/main/java/org/apereo/cas/ticket/expiration/builder/TicketGrantingTicketExpirationPolicyBuilder.java#L63-L98
[2]https://github.com/apereo/cas/blob/v6.1.5/core/cas-server-core-tickets-api/src/main/java/org/apereo/cas/ticket/expiration/TimeoutExpirationPolicy.java#L74
[3]https://github.com/apereo/cas/blob/v6.1.5/core/cas-server-core-tickets-api/src/main/java/org/apereo/cas/ticket/expiration/builder/TicketGrantingTicketExpirationPolicyBuilder.java#L70-L73


--

Ray Bon
Programmer Analyst
Development Services, University Systems
2507218831 | CLE 019 | r...@uvic.ca

I respectfully acknowledge that my place of work is located within the 
ancestral, traditional and unceded territory of the Songhees, Esquimalt and 
WSÁNEĆ Nations.

-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
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.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/cb37f20f7525dd1ebee05de7e10bb7833107c4d6.camel%40uvic.ca.

Re: [cas-user] CAS 6 Attribute Release

2020-06-01 Thread Ray Bon

Bryan,

Maybe these loggers can help.
 






Ray

On Mon, 2020-06-01 at 08:34 -0600, Bryan Wooten wrote:
We are doing a POC with CAS 6. We are building using the war overlay. Are build 
is from the CAS 6 Master branch.

I have a simple Java client app configured for SAML1.1. This app is running on 
the same Tomcat as CAS 6 itself. This is its JSON service registry entry:

{
  "@class" : "org.apereo.cas.services.RegexRegisteredService",
  "serviceId" : "^https://cas6test.go.utah.edu/.*;,
  "name" : "cas6dev-1IdmUtahEdu",
  "id" : 2020052801,
  "description" : "bryan.woo...@utah.edu",
  "logoutType" : "FRONT_CHANNEL",
   "attributeReleasePolicy" : {
"@class" : "org.jasig.cas.services.ReturnAllowedAttributeReleasePolicy",
"allowedAttributes" : [ "java.util.ArrayList", [ "firstName", "lastName", 
"displayName", "email", "homephone", "department", "ou", "cn", 
"telephoneNumber", "acadplan", "almail", "eduPersonAffiliation", "uid", 
"eduPersonPrincipalName", "ummail", "unid", "uudept", "uuemployee", 
"uustudent","psrole" ] ]
  }
}

In the cas.log I see:
allowedAttributes=[firstName, lastName, displayName, email, homephone, 
department, ou, cn, telephoneNumber, acadplan, almail, eduPersonAffiliation, 
uid, eduPersonPrincipalName, ummail, unid, uudept, uuemployee, uustudent, 
psrole]), 
multifactorPolicy=DefaultRegisteredServiceMultifactorPolicy(multifactorAuthenticationProviders=[],
 failureMode=UNDEFINED, principalAttributeNameTrigger=null, 
principalAttributeValueToMatch=null, bypassEnabled=false, forceExecution=false, 
bypassTrustedDeviceEnabled=false, bypassPrincipa

That looks good.

But when the SAML assertion is built it doesn't include those attribute:

Any ideas on what I am missing?


http://schemas.xmlsoap.org/soap/envelope/;>









https://cas6test.go.utah.edu/attrrelease-1.0-SNAPSHOT/attrrelease




u0519980

 




u0519980


urn:oasis:names:tc:SAML:1.0:cm:artifact


http://www.ja-sig.org/products/cas/;>

UsernamePasswordCredential

DuoSecurityCredential

http://www.ja-sig.org/products/cas/;>

urn:oasis:names:tc:SAML:1.0:am:password

urn:oasis:names:tc:SAML:1.0:am:unspecified

http://www.ja-sig.org/products/cas/;>
u0519980

http://www.ja-sig.org/products/cas/;>
true

http://www.ja-sig.org/products/cas/;>
false

http://www.ja-sig.org/products/cas/;>

2020-06-01T13:54:48.138360Z

 http://www.ja-sig.org/products/cas/;>
true

http://www.ja-sig.org/products/cas/;>
false

http://www.ja-sig.org/products/cas/;>

2020-06-01T13:54:48.138360Z

http://www.ja-sig.org/products/cas/;>

LdapAuthenticationHandler
mfa-duo

http://www.ja-sig.org/products/cas/;>
mfa-duo

http://www.ja-sig.org/products/cas/;>

LdapAuthenticationHandler
mfa-duo

http://www.ja-sig.org/products/cas/;>
false

http://www.ja-sig.org/products/cas/;>
BRYAN 
WOOTEN



saml1:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:artifact

Thanks,

Bryan (University of Utah)


--

Ray Bon
Programmer Analyst
Development Services, University Systems
2507218831 | CLE 019 | r...@uvic.ca

I respectfully acknowledge that my place of work is located within the 
ancestral, traditional and unceded territory of the Songhees, Esquimalt and 
WSÁNEĆ Nations.

-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
You received this message because you are subscribed to the Google Groups

[cas-user] cas.ticket.tgt.timeout.maxTimeToLiveInSeconds and Memcache ticket experation policy

2020-06-01 Thread John Bond

Hello All, 

In out config we set both cas.ticket.tgt.timeout.maxTimeToLiveInSeconds and 
cas.ticket.tgt.maxTimeToLiveInSeconds to the same value believing theses 
where the same and  made a note to validate this with this group[1]. That 
later step never happened and the config remained.  however today i tried 
to implement memcache as the ticket store and i noticed via tcpdump that 
CAS was setting the memcache value with an expiry time of -1, this 
effectively means don't cache so when CAS tries to fetch the ticket it 
doesn't exist.   Checking my logs i notice the following debug messages 
which seemed confusing


2020-06-01 14 05 44,597 DEBUG 
[org.apereo.cas.ticket.expiration.builder.TicketGrantingTicketExpirationPolicyBuilder]
 
- 
2020-06-01 14 05 44,599 DEBUG 
[org.apereo.cas.ticket.expiration.builder.TicketGrantingTicketExpirationPolicyBuilder]
 
- 

memcache only supports an int for the expiry however the final value we 
have is 9223372036854775807, my assumption is that this at some point this 
gets coalesced down to -1.  however i'm curious why the final value is not 
604800.

Looking at the code i see that when setting  
`cas.ticket.tgt.timeout.maxTimeToLiveInSeconds` the final timeout value 
comes from TimeoutExpirationPolicy.java which always returns Long.MAX_VALUE[1]. 
 
When setting only `cas.ticket.tgt.maxTimeToLiveInSeconds`  the timeout 
value comes from TicketGrantingTicketExpirationPolicy.java which returns 
`this.maxTimeToLiveInSeconds` which is the value i would expect.  The logic 
that makes this choice is in 
TicketGrantingTicketExpirationPolicyBuilder.java

With this in mind could someone explain the difference between the two 
config items or point me to further documentation.  Further it seems that 
the use of cas.ticket.tgt.timeout.maxTimeToLiveInSeconds is not currently 
compatible with memcache.

We are running CAS 6.5.1 on debian buster, let me know if further 
information is required.

Thanks


[1]https://github.com/apereo/cas/blob/v6.1.5/core/cas-server-core-tickets-api/src/main/java/org/apereo/cas/ticket/expiration/builder/TicketGrantingTicketExpirationPolicyBuilder.java#L63-L98
[2]https://github.com/apereo/cas/blob/v6.1.5/core/cas-server-core-tickets-api/src/main/java/org/apereo/cas/ticket/expiration/TimeoutExpirationPolicy.java#L74
[3]https://github.com/apereo/cas/blob/v6.1.5/core/cas-server-core-tickets-api/src/main/java/org/apereo/cas/ticket/expiration/builder/TicketGrantingTicketExpirationPolicyBuilder.java#L70-L73

-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
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.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/4e3277d1-7093-4d58-b289-29e1073e422e%40apereo.org.

[cas-user] CAS 6 Attribute Release

2020-06-01 Thread Bryan Wooten

We are doing a POC with CAS 6. We are building using the war overlay. Are
build is from the CAS 6 Master branch.

I have a simple Java client app configured for SAML1.1. This app is running
on the same Tomcat as CAS 6 itself. This is its JSON service registry entry:

{
  "@class" : "org.apereo.cas.services.RegexRegisteredService",
  "serviceId" : "^https://cas6test.go.utah.edu/.*;,
  "name" : "cas6dev-1IdmUtahEdu",
  "id" : 2020052801,
  "description" : "bryan.woo...@utah.edu",
  "logoutType" : "FRONT_CHANNEL",
   "attributeReleasePolicy" : {
"@class" : "org.jasig.cas.services.ReturnAllowedAttributeReleasePolicy",
"allowedAttributes" : [ "java.util.ArrayList", [ "firstName",
"lastName", "displayName", "email", "homephone", "department", "ou", "cn",
"telephoneNumber", "acadplan", "almail", "eduPersonAffiliation", "uid",
"eduPersonPrincipalName", "ummail", "unid", "uudept", "uuemployee",
"uustudent","psrole" ] ]
  }
}

In the cas.log I see:
allowedAttributes=[firstName, lastName, displayName, email, homephone,
department, ou, cn, telephoneNumber, acadplan, almail,
eduPersonAffiliation, uid, eduPersonPrincipalName, ummail, unid, uudept,
uuemployee, uustudent, psrole]),
multifactorPolicy=DefaultRegisteredServiceMultifactorPolicy(multifactorAuthenticationProviders=[],
failureMode=UNDEFINED, principalAttributeNameTrigger=null,
principalAttributeValueToMatch=null, bypassEnabled=false,
forceExecution=false, bypassTrustedDeviceEnabled=false, bypassPrincipa

That looks good.

But when the SAML assertion is built it doesn't include those attribute:

Any ideas on what I am missing?


http://schemas.xmlsoap.org/soap/envelope/
">









https://cas6test.go.utah.edu/attrrelease-1.0-SNAPSHOT/attrrelease






u0519980








u0519980


urn:oasis:names:tc:SAML:1.0:cm:artifact


http://www.ja-sig.org/products/cas/;>

UsernamePasswordCredential

DuoSecurityCredential

http://www.ja-sig.org/products/cas/;>

urn:oasis:names:tc:SAML:1.0:am:password

urn:oasis:names:tc:SAML:1.0:am:unspecified

http://www.ja-sig.org/products/cas/;>

u0519980

http://www.ja-sig.org/products/cas/;>
true

http://www.ja-sig.org/products/cas/;>
false

http://www.ja-sig.org/products/cas/;>

2020-06-01T13:54:48.138360Z

 http://www.ja-sig.org/products/cas/;>
true

http://www.ja-sig.org/products/cas/;>
false

http://www.ja-sig.org/products/cas/;>

2020-06-01T13:54:48.138360Z

http://www.ja-sig.org/products/cas/;>

LdapAuthenticationHandler
mfa-duo

http://www.ja-sig.org/products/cas/;>
mfa-duo

http://www.ja-sig.org/products/cas/;>

LdapAuthenticationHandler
mfa-duo

http://www.ja-sig.org/products/cas/;>
false

http://www.ja-sig.org/products/cas/;>
BRYAN
WOOTEN



saml1:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:artifact

Thanks,

Bryan (University of Utah)

-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
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.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAG9x2GUFcdjVkzo5nP%2BOTD3cR_AczB8E67JRqLr8WkGfxRo%3Duw%40mail.gmail.com.

[cas-user] how to include authenticated user's roles in JWT?

2020-06-01 Thread dg

hello,

i have configured cas as oauth2 server. after successfull login, it returns 
JWT, but roles filed in jwt is always empty [].

how can fetch and put authenticated user's role in JWT?

thanks for helps.

-- 
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
--- 
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.
To view this discussion on the web visit 
https://groups.google.com/a/apereo.org/d/msgid/cas-user/94c29c93-7cd9-40cb-b427-bd8584e76a39%40apereo.org.

Re: [cas-user] cas.ticket.tgt.timeout.maxTimeToLiveInSeconds and Memcache ticket experation policy

Re: [cas-user] CAS 6 Attribute Release

[cas-user] CAS 6.1.6 inotify instances skyrocketing with Groovy files in SAML service.

Re: [cas-user] cas.ticket.tgt.timeout.maxTimeToLiveInSeconds and Memcache ticket experation policy

Re: [cas-user] cas.ticket.tgt.timeout.maxTimeToLiveInSeconds and Memcache ticket experation policy

Re: [cas-user] CAS 6 Attribute Release

[cas-user] cas.ticket.tgt.timeout.maxTimeToLiveInSeconds and Memcache ticket experation policy

[cas-user] CAS 6 Attribute Release

[cas-user] how to include authenticated user's roles in JWT?

9 matches

Site Navigation

Mail list logo

Footer information