[cas-user] Re: CAS5.3, SSO between native Mobile App and Web App
Hi Yan, We have built something like this before, And the answer is: yes you can! When user login to webapp using CAS protocol, they can SSO to their native app. However some implementation is needed, I can give you some information on this: - So achieve this, you would want the native app to *not use WebView* to open browser, instead us Chrome Custom Tab for Android / Safari View Controller for iOS - it is quite complicated to setup the Chrome custom tab or Safari View Controller yourself, so I recommend using the AppAuth library (supported by Google) instead: - AppAuth iOS: https://github.com/openid/AppAuth-iOS - AppAuth Android: https://github.com/openid/AppAuth-Android - The behavior is like the below: - When user login to your app, it will pop up a in-app browser inside the app (instead of redirecting to the outside browser / instead of using webview) - Since user already login, CAS will redirect to the redirect_uri, so this screen will flash for a sec - The in-app browser then will be closed, and AppAuth library will handle the rest of the login. In the case where user it not login yet, CAS login screen will be shown, and the flow will be the same after user authenticate successfully See if the above helps you. Cheers! - Andy -- - 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/f49b9248-8903-454c-beb7-51b5073b99d2%40apereo.org.
[cas-user] Re: cas5.3X Multiple system login
Hi Lee, This should not happen, you should be able to login once and it will be fine, please provider some more info, specifically in: - Are you using https or http? http SSO for CAS will not work, if so please change to using https - Do you have your debug log, can you see any issue there? - What is your ticketing system? Are you using the default ticketing system? More information will help us deduce your issue. Cheers! - Andy -- - 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/81e1ed62-a706-4fd1-856e-259a7bf24c5a%40apereo.org.
[cas-user] cas5.3X Multiple system login
With cas5.3x, in the LAN, multiple different systems are connected to the same cas, and you need to log in again when you enter different systems. How do I log in once to enter different systems without logging in? This place is very confused, I found that tiket is saved under / service -- - 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/aec8adc1-bf21-43b5-a0c8-f3d5524e6583%40apereo.org.
[cas-user] CAS5.3, SSO between native Mobile App and Web App
Hello, Say, one webapp using CAS protocol to authenticate against CAS 5.3, another native mobile app uses OpenID Connect to authenticate. When user gets into Mobile app, can he SSO to webapp? Thx, Yan -- - 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/8437a056-9ec7-4b5f-baa7-3c98ef8c1c2d%40apereo.org.
Re: [cas-user] Getting new JWT with CAS
Ray, thank you for clarifications. Right, it probably means instead of 302 response we need to send 401 back and then ajax script needs to call CAS in a different subdomain for a login (that indeed won't require user to provide creds if the CAS login session is still valid). Again, it's all doable, but, I hope, there are ways to avoid these complexities. At the end application has all the information about the user in the application session to place into JWT for sending to an internal microservice. Everything we really need is to generate JWT from this data in a standard centralized way or request a new JWT through CAS On Thursday, April 11, 2019 at 2:10:09 PM UTC-4, rbon wrote: > > Ken, > > I meant invalidate the app session, not the login session. If the CAS > session is still valid, user would not see login screen. > Session invalidation is more of a concern if your app stores data in the > session. > > Ray > > On Thu, 2019-04-11 at 10:56 -0700, Ken Zilber wrote: > > > > > > Thank you for the quick response. > > Sending ajax calls to a subdomain the script did not come from will be an > issue, however, there are solutions (it is doable). My point/question is > that it won't be as seamless/easy as with simple http browser calls > (javascript needs special call handlers, iframes, ...) and I would prefer > to avoid it. > > On another comment - we certainly don't want to invalidate active > application session and ask user to re-login just because our internal JWT > necessary for internal communication expired. > > On Thursday, April 11, 2019 at 1:29:39 PM UTC-4, rbon wrote: > > Ken, > > To clarify, the TGT is not sent to the client. TGC is all that is needed. > If all your apps are on same domain, does CORS apply? > > You could invalidate your app session when JWT expires. App would then > follow normal authentication behaviour and redirect to CAS. This of course > would not work if you stored data in the app session. I suppose it is > possible to have a field in the session to indication authentication (php > probably works like this). > > I have not used JWT nor CAS ajax so take my suggestion as a wild idea. > > Ray > > On Thu, 2019-04-11 at 09:18 -0700, Ken Zilber wrote: > > JWT looks as a nice way for a CASified use-facing application to > communicate with internal REST APIs/microservices. These microservices > can't be accessed by users directly, don't have state and don't need to > deal with sessions and don't need to become CAS controlled services and > correspondingly we don't need to implement CAS protocol with its Proxy > extension that looks a little bit too complex. JWT fits well in this > scenario and CAS can become a great way to generate JWTs for internal > microservice communication. > > It's also clearly described in the CAS documentation that CAS "JWT, the > token itself is not an ID token, cannot be refreshed and must be obtained > again once you deem it expired". > > JWT suppose to be a relatively short lived token as it's not easy to > invalidate it, so we do need a way to obtain a new one when it expires. In > our setting we see two options to do it: > 1. As soon as the user facing CASified application finds that JWT stored > in its user session expired it will issue 302 redirect back to the user > with request to re-login (no need for user enter login/password if TGT is > still valid). This will produce a new JWT. It will work well for the user > http requests, but becomes tricky for the user ajax-like calls due to CORS. > It's still doable particular taking into consideration that our CAS server > and applications are in the same domain, but involves custom client-side > (in the browser) support that concerns me. > 2. Taking an advantage of having CAS server and application in the same > domain we may simply make TGC available for all subdomains in our domain > (not just for CAS server). Then using user's TGT from the cookie, > application may request new JWT on behalf of the user directly from CAS > through a back channel (CAS REST API) when it's needed. I read about > concerns that storing TGT in the application session "opens up a big > security vulnerability". I don't think it would be applied in our case as > application has the TGT only till the user request exists and application > does not try to store it. Still, it would be nice to hear other opinions on > this. > > I appreciate your comments on choosing between #1 and #2 above and it > would be also great to hear about other approaches to centrally generate > JWT with CAS. Thank you. > > -- - 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
Re: [cas-user] Getting new JWT with CAS
Ken, I meant invalidate the app session, not the login session. If the CAS session is still valid, user would not see login screen. Session invalidation is more of a concern if your app stores data in the session. Ray On Thu, 2019-04-11 at 10:56 -0700, Ken Zilber wrote: Thank you for the quick response. Sending ajax calls to a subdomain the script did not come from will be an issue, however, there are solutions (it is doable). My point/question is that it won't be as seamless/easy as with simple http browser calls (javascript needs special call handlers, iframes, ...) and I would prefer to avoid it. On another comment - we certainly don't want to invalidate active application session and ask user to re-login just because our internal JWT necessary for internal communication expired. On Thursday, April 11, 2019 at 1:29:39 PM UTC-4, rbon wrote: Ken, To clarify, the TGT is not sent to the client. TGC is all that is needed. If all your apps are on same domain, does CORS apply? You could invalidate your app session when JWT expires. App would then follow normal authentication behaviour and redirect to CAS. This of course would not work if you stored data in the app session. I suppose it is possible to have a field in the session to indication authentication (php probably works like this). I have not used JWT nor CAS ajax so take my suggestion as a wild idea. Ray On Thu, 2019-04-11 at 09:18 -0700, Ken Zilber wrote: JWT looks as a nice way for a CASified use-facing application to communicate with internal REST APIs/microservices. These microservices can't be accessed by users directly, don't have state and don't need to deal with sessions and don't need to become CAS controlled services and correspondingly we don't need to implement CAS protocol with its Proxy extension that looks a little bit too complex. JWT fits well in this scenario and CAS can become a great way to generate JWTs for internal microservice communication. It's also clearly described in the CAS documentation that CAS "JWT, the token itself is not an ID token, cannot be refreshed and must be obtained again once you deem it expired". JWT suppose to be a relatively short lived token as it's not easy to invalidate it, so we do need a way to obtain a new one when it expires. In our setting we see two options to do it: 1. As soon as the user facing CASified application finds that JWT stored in its user session expired it will issue 302 redirect back to the user with request to re-login (no need for user enter login/password if TGT is still valid). This will produce a new JWT. It will work well for the user http requests, but becomes tricky for the user ajax-like calls due to CORS. It's still doable particular taking into consideration that our CAS server and applications are in the same domain, but involves custom client-side (in the browser) support that concerns me. 2. Taking an advantage of having CAS server and application in the same domain we may simply make TGC available for all subdomains in our domain (not just for CAS server). Then using user's TGT from the cookie, application may request new JWT on behalf of the user directly from CAS through a back channel (CAS REST API) when it's needed. I read about concerns that storing TGT in the application session "opens up a big security vulnerability". I don't think it would be applied in our case as application has the TGT only till the user request exists and application does not try to store it. Still, it would be nice to hear other opinions on this. I appreciate your comments on choosing between #1 and #2 above and it would be also great to hear about other approaches to centrally generate JWT with CAS. Thank you. -- - 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/1933a987fcdf31ddea2165256e1302b794854b8a.camel%40uvic.ca.
Re: [cas-user] Getting new JWT with CAS
Thank you for the quick response. Sending ajax calls to a subdomain the script did not come from will be an issue, however, there are solutions (it is doable). My point/question is that it won't be as seamless/easy as with simple http browser calls (javascript needs special call handlers, iframes, ...) and I would prefer to avoid it. On another comment - we certainly don't want to invalidate active application session and ask user to re-login just because our internal JWT necessary for internal communication expired. On Thursday, April 11, 2019 at 1:29:39 PM UTC-4, rbon wrote: > > Ken, > > To clarify, the TGT is not sent to the client. TGC is all that is needed. > If all your apps are on same domain, does CORS apply? > > You could invalidate your app session when JWT expires. App would then > follow normal authentication behaviour and redirect to CAS. This of course > would not work if you stored data in the app session. I suppose it is > possible to have a field in the session to indication authentication (php > probably works like this). > > I have not used JWT nor CAS ajax so take my suggestion as a wild idea. > > Ray > > On Thu, 2019-04-11 at 09:18 -0700, Ken Zilber wrote: > > JWT looks as a nice way for a CASified use-facing application to > communicate with internal REST APIs/microservices. These microservices > can't be accessed by users directly, don't have state and don't need to > deal with sessions and don't need to become CAS controlled services and > correspondingly we don't need to implement CAS protocol with its Proxy > extension that looks a little bit too complex. JWT fits well in this > scenario and CAS can become a great way to generate JWTs for internal > microservice communication. > > It's also clearly described in the CAS documentation that CAS "JWT, the > token itself is not an ID token, cannot be refreshed and must be obtained > again once you deem it expired". > > JWT suppose to be a relatively short lived token as it's not easy to > invalidate it, so we do need a way to obtain a new one when it expires. In > our setting we see two options to do it: > 1. As soon as the user facing CASified application finds that JWT stored > in its user session expired it will issue 302 redirect back to the user > with request to re-login (no need for user enter login/password if TGT is > still valid). This will produce a new JWT. It will work well for the user > http requests, but becomes tricky for the user ajax-like calls due to CORS. > It's still doable particular taking into consideration that our CAS server > and applications are in the same domain, but involves custom client-side > (in the browser) support that concerns me. > 2. Taking an advantage of having CAS server and application in the same > domain we may simply make TGC available for all subdomains in our domain > (not just for CAS server). Then using user's TGT from the cookie, > application may request new JWT on behalf of the user directly from CAS > through a back channel (CAS REST API) when it's needed. I read about > concerns that storing TGT in the application session "opens up a big > security vulnerability". I don't think it would be applied in our case as > application has the TGT only till the user request exists and application > does not try to store it. Still, it would be nice to hear other opinions on > this. > > I appreciate your comments on choosing between #1 and #2 above and it > would be also great to hear about other approaches to centrally generate > JWT with CAS. Thank you. > > -- - 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/4f6ded35-2cb1-48b5-9220-f821e84e2e05%40apereo.org.
Re: [cas-user] Getting new JWT with CAS
Ken, To clarify, the TGT is not sent to the client. TGC is all that is needed. If all your apps are on same domain, does CORS apply? You could invalidate your app session when JWT expires. App would then follow normal authentication behaviour and redirect to CAS. This of course would not work if you stored data in the app session. I suppose it is possible to have a field in the session to indication authentication (php probably works like this). I have not used JWT nor CAS ajax so take my suggestion as a wild idea. Ray On Thu, 2019-04-11 at 09:18 -0700, Ken Zilber wrote: JWT looks as a nice way for a CASified use-facing application to communicate with internal REST APIs/microservices. These microservices can't be accessed by users directly, don't have state and don't need to deal with sessions and don't need to become CAS controlled services and correspondingly we don't need to implement CAS protocol with its Proxy extension that looks a little bit too complex. JWT fits well in this scenario and CAS can become a great way to generate JWTs for internal microservice communication. It's also clearly described in the CAS documentation that CAS "JWT, the token itself is not an ID token, cannot be refreshed and must be obtained again once you deem it expired". JWT suppose to be a relatively short lived token as it's not easy to invalidate it, so we do need a way to obtain a new one when it expires. In our setting we see two options to do it: 1. As soon as the user facing CASified application finds that JWT stored in its user session expired it will issue 302 redirect back to the user with request to re-login (no need for user enter login/password if TGT is still valid). This will produce a new JWT. It will work well for the user http requests, but becomes tricky for the user ajax-like calls due to CORS. It's still doable particular taking into consideration that our CAS server and applications are in the same domain, but involves custom client-side (in the browser) support that concerns me. 2. Taking an advantage of having CAS server and application in the same domain we may simply make TGC available for all subdomains in our domain (not just for CAS server). Then using user's TGT from the cookie, application may request new JWT on behalf of the user directly from CAS through a back channel (CAS REST API) when it's needed. I read about concerns that storing TGT in the application session "opens up a big security vulnerability". I don't think it would be applied in our case as application has the TGT only till the user request exists and application does not try to store it. Still, it would be nice to hear other opinions on this. I appreciate your comments on choosing between #1 and #2 above and it would be also great to hear about other approaches to centrally generate JWT with CAS. Thank you. -- - 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/b240c4091372f26d3af98a65fdd6c21c431d9d9c.camel%40uvic.ca.
[cas-user] Getting new JWT with CAS
JWT looks as a nice way for a CASified use-facing application to communicate with internal REST APIs/microservices. These microservices can't be accessed by users directly, don't have state and don't need to deal with sessions and don't need to become CAS controlled services and correspondingly we don't need to implement CAS protocol with its Proxy extension that looks a little bit too complex. JWT fits well in this scenario and CAS can become a great way to generate JWTs for internal microservice communication. It's also clearly described in the CAS documentation that CAS "JWT, the token itself is not an ID token, cannot be refreshed and must be obtained again once you deem it expired". JWT suppose to be a relatively short lived token as it's not easy to invalidate it, so we do need a way to obtain a new one when it expires. In our setting we see two options to do it: 1. As soon as the user facing CASified application finds that JWT stored in its user session expired it will issue 302 redirect back to the user with request to re-login (no need for user enter login/password if TGT is still valid). This will produce a new JWT. It will work well for the user http requests, but becomes tricky for the user ajax-like calls due to CORS. It's still doable particular taking into consideration that our CAS server and applications are in the same domain, but involves custom client-side (in the browser) support that concerns me. 2. Taking an advantage of having CAS server and application in the same domain we may simply make TGC available for all subdomains in our domain (not just for CAS server). Then using user's TGT from the cookie, application may request new JWT on behalf of the user directly from CAS through a back channel (CAS REST API) when it's needed. I read about concerns that storing TGT in the application session "opens up a big security vulnerability". I don't think it would be applied in our case as application has the TGT only till the user request exists and application does not try to store it. Still, it would be nice to hear other opinions on this. I appreciate your comments on choosing between #1 and #2 above and it would be also great to hear about other approaches to centrally generate JWT with CAS. Thank you. -- - 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/0977ff26-8b01-48ee-a182-72458a343c40%40apereo.org.
[cas-user] Refreshing/
JWT looks as a nice way for a CASified use-facing application to communicate with internal REST APIs/microservices. These microservices can't be accessed by users directly, don't have state and don't need to deal with sessions and don't need to become CAS controlled services and correspondingly we don't need to implement CAS protocol with its Proxy extension that looks a little bit too complex. JWT fits well in this scenario and CAS can become a great way to generate JWTs for internal microservice communication. It's also clearly described in the CAS documentation that CAS "JWT, the token itself is not an ID token, cannot be refreshed and must be obtained again once you deem it expired". JWT suppose to be a relatively short lived token as it's not easy to invalidate it, so we do need a way to obtain a new one when it expires. In our setting we see two options to do it: 1. As soon as the user facing CASified application finds that JWT stored in its user session expired it will issue 302 redirect back to the user with request to re-login (no need for user enter login/password if TGT is still valid). This will produce a new JWT. It will work well for the user http requests, but becomes tricky for the user ajax-like calls due to CORS. It's still doable particular taking into consideration that our CAS server and applications are in the same domain, but involves custom client-side (in the browser) support that concerns me. 2. Taking an advantage of having CAS server and application in the same domain we may simply make TGC available for all subdomains in our domain (not just for CAS server). Then using user's TGT from the cookie, application may request new JWT on behalf of the user directly from CAS through a back channel (CAS REST API) when it's needed. I read about concerns that storing TGT in the application session "opens up a big security vulnerability". I don't think it would be applied in our case as application has the TGT only till the user request exists and application does not try to store it. Still, it would be nice to hear other opinions on this. I appreciate your comments on choosing between #1 and #2 above and it would be also great to hear about other approaches to centrally generate JWT with CAS. Thank you. -- - 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/5f2d5e0a-7d7d-480c-afa5-8ffe0995cba5%40apereo.org.
Re: [cas-user] Re: Help CAS Management Error (CAS Server returned 502 status code from endpoint https://cas.example.com/cas/status/discovery. Using default FormData values)
Thanks Julien for your reply.
It looks like it's a static attribute. I once configured:
> ... principalAttributeList = uid, displayName, phoneNumber, emailAddress
Then I added the homeAddress attribute to database, the homeAddress attribute
is not registering (configured) to principalAttributeList, so that the option
in the CAS Management dropdown (Return Allowed Attributes) does not shown.
Note: I use JDBC in Multi-Row mode. So the CAS administrator can add attributes
to the database.
After you configure it, can you choose the attribute list in CAS Management
(the Attribute Release Policy, Return Allowed tab)?
How do you make principalAttributeList based on JDBC Multi-Row?
Thanks
Sent from my iPhone
> On 11 Apr 2019, at 15.53, Julien Gribonvald
> wrote:
>
> Hi,
>
> I have yesterday the same problem on a delegated auth and I needed to watch
> on cas properties (as it's not listed).
>
> On my case users can come from several auth systems, one is local from my
> LDAP, but users can use a delegated auth. So in my conf I have the basic auth
> from my local LDAP defined with cas.authn.ldap[0]. and as example
> for a delegated auth from a shibboleth IDP I defined
> cas.authn.pac4j.saml[0].
>
> But in the case of a delegated auth I need to chain this auth with a local
> LDAP request to obtain user's attributes and so I need to define such
> properties: cas.authn.attributeRepository.ldap[0].
>
> But this doesn't permit to merge users attributes from my local LDAP, and
> after search I've found this property that permit to share all attributes
> retrieved :
> cas.authn.attributeRepository.defaultAttributesToRelease=${cas.authn.ldap[0].principalAttributeList}
> where cas.authn.ldap[0].principalAttributeList is my default local LDAP auth
> user attributes list, and so I have the same list.
>
> Hope this will help you !
>
> Now on my case, as I have several delegated system, I'm looking for if it's
> possible to set something that tell to use one specific attributeRepository
> associated to a specific delegated auth (due to the LDAP filter won't be the
> same) instead of chaining all attributeRepository.
>
> Thanks
>
> Julien
>
>
>
>> Le 11/04/2019 à 02:58, Fahmi L. Ramdhani a écrit :
>> CAS Management can't retrieve the list of attributes available on CAS Server?
>>
>> I have added configuration to management.properties, but it didn't work. CAS
>> Management only contains the default attributes (uid, eppn, givenName).
>>
>> I have tried adding the STUB configuration, unfortunately it is static.
>>
>>> ... attributeRepository.stub.attributes.uid = uid
>>> .
>>
>> I hope CAS Management can take available attributes based on the CAS Server
>> configuration.
>>
>> Can anyone give me a suggestion for what i want?
>>
>> Sent from my iPhone
>>
>> On 10 Apr 2019, at 23.03, Ray Bon wrote:
>>
>>> Fahmi,
>>>
>>> Our management server is too old to have this feature.
>>> Start here,
>>> https://apereo.github.io/cas/5.3.x/integration/Attribute-Release.html
>>> You probably have to add properties to management service properties file.
>>>
>>> Ray
>>>
On Tue, 2019-04-09 at 17:57 -0700, Fahmi L. Ramdhani wrote:
Thank you for the quick reply.
First I accessed via the browser
https://cas.example.com/cas/status/discovery, then CAS directed to login.
After successfully logging in, the results are like this:
{
"@class": "java.util.LinkedHashMap",
"profile": {
"@class": "org.apereo.cas.discovery.CasServerProfile",
"registeredServiceTypes": {
"@class": "java.util.HashMap",
"CAS Client": "org.apereo.cas.services.RegexRegisteredService"
},
"registeredServiceTypesSupported": {
"@class": "java.util.HashMap",
"SAML2 Service Provider":
"org.apereo.cas.support.saml.services.SamlRegisteredService",
"WS Federation Relying Party":
"org.apereo.cas.ws.idp.services.WSFederationRegisteredService",
"OpenID Connect Relying Party":
"org.apereo.cas.services.OidcRegisteredService",
"OAuth2 Client":
"org.apereo.cas.support.oauth.services.OAuthRegisteredService",
"CAS Client": "org.apereo.cas.services.RegexRegisteredService"
},
"multifactorAuthenticationProviderTypesSupported": {
"@class": "java.util.HashMap",
"mfa-gauth": "Google Authenticator",
"mfa-swivel": "Swivel Secure",
"mfa-authy": "Authy",
"mfa-radius": "RADIUS (RSA,WiKID)",
"mfa-u2f": "FIDO U2F",
"mfa-azure": "Microsoft Azure",
"mfa-duo": "Duo Security"
},
"delegatedClientTypesSupported": [
"java.util.HashSet",
[
"OAuth20Client",
"OAuth10Client",
"TwitterClient",
"FoursquareClient",
"QQClient",
[cas-user] Re: Send reset password email in html instead of plain text
Just opened a new topic at CAS developer: https://groups.google.com/a/apereo.org/forum/#!topic/cas-dev/hdEXtWk9yQg On Thursday, April 11, 2019 at 12:03:34 PM UTC+2, Michele Melluso wrote: > > > Hi, > > I made your same path in finding a solution. > > Our problem is that the reset link in plain text is misinterpreted by > apple mail client, and when users click the link, the token is truncated at > the first dot occurrence. > > @cas developers > Would it be a possibility to add a property to be used to eventually add > the 'true' for html text? If so we could even submit a pull request about > it. > > best regards > Michele > > > > > > On Monday, March 26, 2018 at 5:59:16 PM UTC+2, Marc Maurice wrote: >> >> Hello all, >> >> We need to send the reset password email in html instead of plain text >> (marketing demands). >> >> Looking at the source code it seems simple. It's just a matter of adding >> a "true" parameter to tell spring that the email is in html : >> >> >> https://github.com/apereo/cas/blob/5.2.x/core/cas-server-core-util/src/main/java/org/apereo/cas/util/io/CommunicationsManager.java#L102 >> >> https://docs.spring.io/spring/docs/3.0.0.M3/reference/html/ch26s03.html >> >> Do you know any simple way to patch the cas server core using the overlay >> way ? Or do we have to compile the entire stack ? >> >> We really would like to keep the overlay system, in order to ease future >> updates. >> >> Thanks in advance, >> Marc >> > -- - 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/d572b27d-a360-4ba1-8785-37f61560f9c0%40apereo.org.
[cas-user] Re: Send reset password email in html instead of plain text
Hi, I made your same path in finding a solution. Our problem is that the reset link in plain text is misinterpreted by apple mail client, and when users click the link, the token is truncated at the first dot occurrence. @cas developers Would it be a possibility to add a property to be used to eventually add the 'true' for html text? If so we could even submit a pull request about it. best regards Michele On Monday, March 26, 2018 at 5:59:16 PM UTC+2, Marc Maurice wrote: > > Hello all, > > We need to send the reset password email in html instead of plain text > (marketing demands). > > Looking at the source code it seems simple. It's just a matter of adding a > "true" parameter to tell spring that the email is in html : > > > https://github.com/apereo/cas/blob/5.2.x/core/cas-server-core-util/src/main/java/org/apereo/cas/util/io/CommunicationsManager.java#L102 > > https://docs.spring.io/spring/docs/3.0.0.M3/reference/html/ch26s03.html > > Do you know any simple way to patch the cas server core using the overlay > way ? Or do we have to compile the entire stack ? > > We really would like to keep the overlay system, in order to ease future > updates. > > Thanks in advance, > Marc > -- - 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/47369509-9b84-451a-b34b-005d342c554d%40apereo.org.
Re: [cas-user] Re: Help CAS Management Error (CAS Server returned 502 status code from endpoint https://cas.example.com/cas/status/discovery. Using default FormData values)
Hi,
I have yesterday the same problem on a delegated auth and I needed to
watch on cas properties (as it's not listed).
On my case users can come from several auth systems, one is local from
my LDAP, but users can use a delegated auth. So in my conf I have the
basic auth from my local LDAP defined with *cas.authn.ldap[0]. *and
as example for a delegated auth from a shibboleth IDP I defined
*cas.authn.pac4j.saml[0].*
But in the case of a delegated auth I need to chain this auth with a
local LDAP request to obtain user's attributes and so I need to define
such properties: *cas.authn.attributeRepository.ldap[0].*
But this doesn't permit to merge users attributes from my local LDAP,
and after search I've found this property that permit to share all
attributes retrieved :
*cas.authn.attributeRepository.defaultAttributesToRelease=${cas.authn.ldap[0].principalAttributeList}*
where *cas.authn.ldap[0].principalAttributeList* is my default local
LDAP auth user attributes list, and so I have the same list.
Hope this will help you !
Now on my case, as I have several delegated system, I'm looking for if
it's possible to set something that tell to use one specific
attributeRepository associated to a specific delegated auth (due to the
LDAP filter won't be the same) instead of chaining all attributeRepository.
Thanks
Julien
Le 11/04/2019 à 02:58, Fahmi L. Ramdhani a écrit :
CAS Management can't retrieve the list of attributes available on CAS
Server?
I have added configuration to management.properties, but it didn't
work. CAS Management only contains the default attributes (uid, eppn,
givenName).
I have tried adding the STUB configuration, unfortunately it is static.
... attributeRepository.stub.attributes.uid = uid
.
I hope CAS Management can take available attributes based on the CAS
Server configuration.
Can anyone give me a suggestion for what i want?
Sent from my iPhone
On 10 Apr 2019, at 23.03, Ray Bon mailto:r...@uvic.ca>>
wrote:
Fahmi,
Our management server is too old to have this feature.
Start here,
https://apereo.github.io/cas/5.3.x/integration/Attribute-Release.html
You probably have to add properties to management service properties
file.
Ray
On Tue, 2019-04-09 at 17:57 -0700, Fahmi L. Ramdhani wrote:
Thank you for the quick reply.
First I accessed via the browser
https://cas.example.com/cas/status/discovery, then CAS directed to
login. After successfully logging in, the results are like this:
{
"@class": "java.util.LinkedHashMap",
"profile": {
"@class": "org.apereo.cas.discovery.CasServerProfile",
"registeredServiceTypes": {
"@class": "java.util.HashMap",
"CAS Client": "org.apereo.cas.services.RegexRegisteredService"
},
"registeredServiceTypesSupported": {
"@class": "java.util.HashMap",
"SAML2 Service Provider":
"org.apereo.cas.support.saml.services.SamlRegisteredService",
"WS Federation Relying Party":
"org.apereo.cas.ws.idp.services.WSFederationRegisteredService",
"OpenID Connect Relying Party":
"org.apereo.cas.services.OidcRegisteredService",
"OAuth2 Client":
"org.apereo.cas.support.oauth.services.OAuthRegisteredService",
"CAS Client": "org.apereo.cas.services.RegexRegisteredService"
},
"multifactorAuthenticationProviderTypesSupported": {
"@class": "java.util.HashMap",
"mfa-gauth": "Google Authenticator",
"mfa-swivel": "Swivel Secure",
"mfa-authy": "Authy",
"mfa-radius": "RADIUS (RSA,WiKID)",
"mfa-u2f": "FIDO U2F",
"mfa-azure": "Microsoft Azure",
"mfa-duo": "Duo Security"
},
"delegatedClientTypesSupported": [
"java.util.HashSet",
[
"OAuth20Client",
"OAuth10Client",
"TwitterClient",
"FoursquareClient",
"QQClient",
"OrcidClient",
"FacebookClient",
"OkClient",
"FormClient",
"CasProxyReceptor",
"GitHubClient",
"KeycloakOidcClient",
"BitbucketClient",
"WordPressClient",
"OidcClient",
"WindowsLiveClient",
"VkClient",
"LinkedIn2Client",
"YahooClient",
"WechatClient",
"Google2Client",
"StravaClient",
"GenericOAuth20Client",
"AzureAdClient",
"GoogleOidcClient",
"CasOAuthWrapperClient",
"PayPalClient",
"WeiboClient",
"DropBoxClient",
"SAML2Client",
"CasClient",
"IndirectBasicAuthClient"
]
],
*"availableAttributes": [*
*"java.util.LinkedHashSet",*
* [*
* "mail",*
* "eppn",*
*"displayName",*
*"givenName",*
* "uid"*
* ]*
* ]*
}
}
You can see the availableAttributes section? I need it to make it
easier for CAS administrators to release attributes for each
service. But when I access
*/https://cas.example.com/cas-management/* and try to add services,
the */"mail", "eppn", "displayName",
[cas-user] CAS 6.0.3 - The request was rejected because the URL was not normalized.
Hi! Having problems upgrading from 5.3.5 to 6.0.3 on docker. Running fine on localhost (http), but getting errors like below on rc (https): 2019-04-11 07:19:02,477 ERROR [org.springframework.boot.web.servlet.support.ErrorPageFilter] - org.springframework.security.web.firewall.RequestRejectedException: The request was rejected because the URL was not normalized. at org.springframework.security.web.firewall.StrictHttpFirewall.getFirewalledRequest(StrictHttpFirewall.java:296) ~[spring-security-web-5.1.2.RELEASE.jar:5.1.2.RELEASE] at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:194) ~[spring-security-web-5.1.2.RELEASE.jar:5.1.2.RELEASE] at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:178) ~[spring-security-web-5.1.2.RELEASE.jar:5.1.2.RELEASE] at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:357) ~[spring-web-5.1.3.RELEASE.jar:5.1.3.RELEASE] at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:270) ~[spring-web-5.1.3.RELEASE.jar:5.1.3.RELEASE] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[catalina.jar:9.0.17] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[catalina.jar:9.0.17] at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99) ~[spring-web-5.1.3.RELEASE.jar:5.1.3.RELEASE] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) ~[spring-web-5.1.3.RELEASE.jar:5.1.3.RELEASE] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[catalina.jar:9.0.17] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[catalina.jar:9.0.17] at org.springframework.web.filter.FormContentFilter.doFilterInternal(FormContentFilter.java:92) ~[spring-web-5.1.3.RELEASE.jar:5.1.3.RELEASE] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) ~[spring-web-5.1.3.RELEASE.jar:5.1.3.RELEASE] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[catalina.jar:9.0.17] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[catalina.jar:9.0.17] at org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:93) ~[spring-web-5.1.3.RELEASE.jar:5.1.3.RELEASE] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) ~[spring-web-5.1.3.RELEASE.jar:5.1.3.RELEASE] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[catalina.jar:9.0.17] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[catalina.jar:9.0.17] at org.springframework.boot.web.servlet.support.ErrorPageFilter.doFilter(ErrorPageFilter.java:130) ~[spring-boot-2.1.2.RELEASE.jar:2.1.2.RELEASE] at org.springframework.boot.web.servlet.support.ErrorPageFilter.access$000(ErrorPageFilter.java:66) ~[spring-boot-2.1.2.RELEASE.jar:2.1.2.RELEASE] at org.springframework.boot.web.servlet.support.ErrorPageFilter$1.doFilterInternal(ErrorPageFilter.java:105) ~[spring-boot-2.1.2.RELEASE.jar:2.1.2.RELEASE] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) ~[spring-web-5.1.3.RELEASE.jar:5.1.3.RELEASE] at org.springframework.boot.web.servlet.support.ErrorPageFilter.doFilter(ErrorPageFilter.java:123) ~[spring-boot-2.1.2.RELEASE.jar:2.1.2.RELEASE] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[catalina.jar:9.0.17] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) ~[catalina.jar:9.0.17] at org.springframework.boot.actuate.metrics.web.servlet.WebMvcMetricsFilter.filterAndRecordMetrics(WebMvcMetricsFilter.java:117) ~[spring-boot-actuator-2.1.2.RELEASE.jar:2.1.2.RELEASE] at org.springframework.boot.actuate.metrics.web.servlet.WebMvcMetricsFilter.doFilterInternal(WebMvcMetricsFilter.java:106) ~[spring-boot-actuator-2.1.2.RELEASE.jar:2.1.2.RELEASE] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) ~[spring-web-5.1.3.RELEASE.jar:5.1.3.RELEASE] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) ~[catalina.jar:9.0.17] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
