read point 2 of previously attached flow. 2018-02-28 14:06 GMT-03:00 Tim Tyler <[email protected]>:
> Should both the IdP and SP need each other’s SAML metadata content? I ask > because I am suspicious that the Jenzabar JICS side has no configuration > pointing to the CAS metadata.xml content. They point to the CAS login, but > I don’t think they have a configuration pointing to the CAS metadata. I am > also very concerned about the content in idp-metadat.xml, but that might be > a moot point at the moment if the content is not begin accessed by the SP. > > > > Tim > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Man > H > *Sent:* Wednesday, February 28, 2018 10:24 AM > *To:* [email protected] > *Subject:* Re: [cas-user] SAML and Jenzabar JICS > > > > > > I suggest: > > - look int cas metadata idp-metadata.xml > > - enable saml debug > > <AsyncLogger name="org.opensaml" level="debug" additivity="false"> > > <AppenderRef ref="console"/> > > <AppenderRef ref="file"/> > > </AsyncLogger> > > > > Assuming cas is your idp and Jenzabar your SP. > > The processing is as follows: > > 1. The user attempts to access a resource on sp.example.com. The > user does not have a valid logon session (i.e. security context) on this > site. The SP saves the requested resource URL in local state information > that can be saved across the web SSO exchange. > > 2. The SP sends an HTML form back to the browser in the HTTP > response (HTTP status 200). The HTML FORM contains a SAML <AuthnRequest> > message encoded as the value of a hidden form control named SAMLRequest. > > <form method="post" action="https://idp.example.org/SAML2/SSO/POST"; ...> > > <input type="hidden" name="SAMLRequest" value="request" /> > > <input type="hidden" name="RelayState" value="token" /> > > ... > > <input type="submit" value="Submit" /> > > </form> > > The RelayState token is an opaque reference to state information > maintained at the service provider. (The RelayState mechanism can leak > details of the user's activities at the SP to the IdP and so the SP should > take care in its implementation to protect the user's privacy.) The value > of the SAMLRequest parameter is the base64 encoding of the following > <samlp:AuthnRequest> element: > > <samlp:AuthnRequest > > xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > > xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" > > ID="identifier_1" > > Version="2.0" > > IssueInstant="2004-12-05T09:21:59Z" > > AssertionConsumerServiceIndex="1"> > > <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer> > > <samlp:NameIDPolicy > > AllowCreate="true" > > Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/> > > </samlp:AuthnRequest> > > 1. For ease-of-use purposes, the HTML FORM typically will be > accompanied by script code that will automatically post the form to the > destination site (which is the IdP in this case). The browser, due either > to a user action or execution of an “auto-submit” script, issues an HTTP > POST request to send the form to the identity provider's Single Sign-On > Service. > > POST /SAML2/SSO/POST HTTP/1.1 > > Host: idp.example.org > > Content-Type: application/x-www-form-urlencoded > > Content-Length: nnn > > SAMLRequest=request&RelayState=token > > 3. The Single Sign-On Service determines whether the user has an > existing logon security context at the identity provider that meets the > default or requested authentication policy requirements. If not, the IdP > interacts with the browser to challenge the user to provide valid > credentials. > > 4. The user provides valid credentials and a local logon security > context is created for the user at the IdP. > > 5. The IdP Single Sign-On Service issues a SAML assertion > representing the user's logon security context and places the assertion > within a SAML <Response> message. Since the HTTP Artifact binding will be > used to deliver the SAML Response message, it is not mandated that the > assertion be digitally signed. The IdP creates an artifact containing the > source ID for the idp.example.org site and a reference to the <Response> > message > (the MessageHandle). The HTTP Artifact binding allows the choice of > either HTTP redirection or an HTML form POST as the mechanism to deliver > the artifact to the partner. The figure shows the use of redirection. > > 6. The SP's Assertion Consumer Service now sends a SAML > <ArtifactResolve> message containing the artifact to the IdP's Artifact > Resolution Service endpoint. This exchange is performed using a > synchronous SOAP message exchange. > > <samlp:ArtifactResolve > > xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > > xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" > > ID="identifier_2" > > Version="2.0" > > IssueInstant="2004-12-05T09:22:04Z" > > Destination="https://idp.example.org/SAML2/ArtifactResolution";> > > <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer> > > <!-- an ArtifactResolve message SHOULD be signed --> > > <ds:Signature > > xmlns:ds="http://www.w3.org/2000/09/xmldsig# > <http://www.w3.org/2000/09/xmldsig>">...</ds:Signature> > > <samlp:Artifact>artifact</samlp:Artifact> > > </samlp:ArtifactResolve> > > 7. The IdP's Artifact Resolution Service extracts the MessageHandle > from the artifact and locates the original SAML <Response> message > associated with it. This message is then placed inside a SAML > <ArtifactResponse> message, which is returned to the SP over the SOAP > channel. > > <samlp:ArtifactResponse > > xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > > ID="identifier_3" > > InResponseTo="identifier_2" > > Version="2.0" > > IssueInstant="2004-12-05T09:22:05Z"> > > <!-- an ArtifactResponse message SHOULD be signed --> > > <ds:Signature > > xmlns:ds="http://www.w3.org/2000/09/xmldsig# > <http://www.w3.org/2000/09/xmldsig>">...</ds:Signature> > > <samlp:Status> > > <samlp:StatusCode > > Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> > > </samlp:Status> > > <samlp:Response > > xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > > xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" > > ID="identifier_4" > > InResponseTo="identifier_1" > > Version="2.0" > > IssueInstant="2004-12-05T09:22:05Z" > > Destination="https://sp.example.com/SAML2/SSO/Artifact";> > > <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer> > > <ds:Signature > > xmlns:ds="http://www.w3.org/2000/09/xmldsig# > <http://www.w3.org/2000/09/xmldsig>">...</ds:Signature> > > <samlp:Status> > > <samlp:StatusCode > > Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> > > </samlp:Status> > > <saml:Assertion > > xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" > > ID="identifier_5" > > Version="2.0" > > IssueInstant="2004-12-05T09:22:05Z"> > > <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer> > > <!-- a Subject element is required --> > > <saml:Subject> > > <saml:NameID > > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> > > [email protected] > > </saml:NameID> > > <saml:SubjectConfirmation > > Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> > > <saml:SubjectConfirmationData > > InResponseTo="identifier_1" > > Recipient="https://sp.example.com/SAML2/SSO/Artifact"; > > NotOnOrAfter="2004-12-05T09:27:05Z"/> > > </saml:SubjectConfirmation> > > </saml:Subject> > > <saml:Conditions > > NotBefore="2004-12-05T09:17:05Z" > > NotOnOrAfter="2004-12-05T09:27:05Z"> > > <saml:AudienceRestriction> > > <saml:Audience>https://sp.example.com/SAML2</saml:Audience> > > </saml:AudienceR > > I suggest: > > - look int cas metadata idp-metadata.xml > > - enable saml debug > > <AsyncLogger name="org.opensaml" level="debug" additivity="false"> > > <AppenderRef ref="console"/> > > <AppenderRef ref="file"/> > > </AsyncLogger> > > estriction> > > The processing is as follows: > > 1. The user attempts to access a resource on sp.example.com. The user > does not have a valid logon session (i.e. security context) on this site. > The SP saves the requested resource URL in local state information that can > be saved across the web SSO exchange. > > 2. The SP sends an HTML form back to the browser in the HTTP response > (HTTP status 200). The HTML FORM contains a SAML <AuthnRequest> message > encoded as the value of a hidden form control named SAMLRequest. > > <form method="post" action="https://idp.example.org/SAML2/SSO/POST"; ...> > > <input type="hidden" name="SAMLRequest" value="request" /> > > <input type="hidden" name="RelayState" value="token" /> > > ... > > <input type="submit" value="Submit" /> > > </form> > > The RelayState token is an opaque reference to state information > maintained at the service provider. (The RelayState mechanism can leak > details of the user's activities at the SP to the IdP and so the SP should > take care in its implementation to protect the user's privacy.) The value > of the SAMLRequest parameter is the base64 encoding of the following > <samlp:AuthnRequest> element: > > <samlp:AuthnRequest > > xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > > xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" > > ID="identifier_1" > > Version="2.0" > > IssueInstant="2004-12-05T09:21:59Z" > > AssertionConsumerServiceIndex="1"> > > <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer> > > <samlp:NameIDPolicy > > AllowCreate="true" > > Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/> > > </samlp:AuthnRequest> > > 1. For ease-of-use purposes, the HTML FORM typically will be accompanied > by script code that will automatically post the form to the destination > site (which is the IdP in this case). The browser, due either to a user > action or execution of an “auto-submit” script, issues an HTTP POST request > to send the form to the identity provider's Single Sign-On Service. > > POST /SAML2/SSO/POST HTTP/1.1 > > Host: idp.example.org > > Cidp-metadata.xmlontent-Type: application/x-www-form-urlencoded > > Content-Length: nnn > > SAMLRequest=request&RelayState=token > > 3. The Single Sign-On Service determines whether the user has an > existing logon security context at the identity provider that meets the > default or requested authentication policy requirements. If not, the IdP > interacts with the browser to challenge the user to provide valid > credentials. > > 4. The user provides valid credentials and a local logon security > context is created for the user at the IdP. > > 5. The IdP Single Sign-On Service issues a SAML assertion representing > the user's logon security context and places the assertion within a SAML > <Response> message. Since the HTTP Artifact binding will be used to > deliver the SAML Response message, it is not mandated that the assertion be > digitally signed. The IdP creates an artifact containing the source ID for > the idp.example.org site and a reference to the <Response> message (the > MessageHandle). The HTTP Artifact binding allows the choice of either HTTP > redirection or an HTML form POST as the mechanism to deliver the artifact > to the partner. The figure shows the use of redirection. > > 6. The SP's Assertion Consumer Service now sends a SAML > <ArtifactResolve> message containing the artifact to the IdP's Artifact > Resolution Service endpoint. This exchange is performed using a > synchronous SOAP message exchange. > > <samlp:ArtifactResolve > > xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > > xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" > > ID="identifier_2" > > Version="2.0" > > IssueInstant="2004-12-05T09:22:04Z" > > Destination="https://idp.example.org/SAML2/ArtifactResolution";> > > <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer> > > <!-- an ArtifactResolve message SHOULD be signed --> > > <ds:Signature > > xmlns:ds="http://www.w3.org/2000/09/xmldsig# > <http://www.w3.org/2000/09/xmldsig>">...</ds:Signature> > > <samlp:Artifact>artifact</samlp:Artifact> > > </samlp:ArtifactResolve> > > 7. The IdP's Artifact Resolution Service extracts the MessageHandle from > the artifact and locates the original SAML <Response> message associated > with it. This message is then placed inside a SAML <ArtifactResponse> > message, which is returned to the SP over the SOAP channel. > > <samlp:ArtifactResponse > > xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > > ID="identifier_3" > > InResponseTo="identifier_2" > > Version="2.0" > > IssueInstant="2004-12-05T09:22:05Z"> > > <!-- an ArtifactResponse message SHOULD be signed --> > > <ds:Signature > > xmlns:ds="http://www.w3.org/2000/09/xmldsig# > <http://www.w3.org/2000/09/xmldsig>">...</ds:Signature> > > <samlp:Status> > > <samlp:StatusCode > > Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> > > </samlp:Status> > > <samlp:Response > > xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > > xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" > > ID="identifier_4" > > InResponseTo="identifier_1" > > Version="2.0" > > IssueInstant="2004-12-05T09:22:05Z" > > Destination="https://sp.example.com/SAML2/SSO/Artifact";> > > <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer> > > <ds:Signature > > xmlns:ds="http://www.w3.org/2000/09/xmldsig# > <http://www.w3.org/2000/09/xmldsig>">...</ds:Signature> > > <samlp:Status> > > <samlp:StatusCode > > Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> > > </samlp:Status> > > <saml:Assertion > > xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" > > ID="identifier_5" > > Version="2.0" > > IssueInstant="2004-12-05T09:22:05Z"> > > <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer> > > <!-- a Subject element is required --> > > <saml:Subject> > > <saml:NameID > > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"> > > [email protected] > > </saml:NameID> > > <saml:SubjectConfirmation > > Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> > > <saml:SubjectConfirmationData > > InResponseTo="identifier_1" > > Recipient="https://sp.example.com/SAML2/SSO/Artifact"; > > NotOnOrAfter="2004-12-05T09:27:05Z"/> > > </saml:SubjectConfirmation> > > </saml:Subject> > > <saml:Conditions > > NotBefore="2004-12-05T09:17:05Z" > > NotOnOrAfter="2004-12-05T09:27:05Z"> > > <saml:AudienceRestriction> > > <saml:Audience>https://sp.example.com/SAML2</saml:Audience> > > </saml:AudienceRestriction> > > </saml:Conditions> > > <saml:AuthnStatement > > AuthnInstant="2004-12-05T09:22:00Z" > > SessionIndex="identifier_5"> > > <saml:AuthnContext> > > <saml:AuthnContextClassRef> > > urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport > > </saml:AuthnContextClassRef> > > </saml:AuthnContext> > > </saml:AuthnStatement> > > </saml:Assertion> > > </samlp:Response> > > </samlp:ArtifactResponse> > > The SP extracts and processes the <Response> message and then processes > the embedded assertion in order to create a local logon security context > for the user at the SP. Once this is completed, the SP retrieves the local > state information indicated by the RelayState data to recall the > originally-requested resource URL. It then sends an HTTP redirect > response to the browser directing it to access the originally requested > resource (not shown). > > 7. An access check is made to establish whether the user has the correct > authorization to access the resource. If the access check passes, the > resource is then returned to the browser. > > </saml:Conditions> > > <saml:AuthnStatement > > AuthnInstant="2004-12-05T09:22:00Z" > > SessionIndex="identifier_5"> > > <saml:AuthnContext> > > <saml:AuthnContextClassRef> > > urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport > > </saml:AuthnContextClassRef> > > </saml:AuthnContext> > > </saml:AuthnStatement> > > </saml:Assertion> > > </samlp:Response> > > </samlp:ArtifactResponse> > > The SP extracts and processes the <Response> message and then processes > the embedded assertion in order to create a local logon security context > for the user at the SP. Once this is completed, the SP retrieves the local > state information indicated by the RelayState data to recall the > originally-requested resource URL. It then sends an HTTP redirect > response to the browser directing it to access the originally requested > resource (not shown). > > 7. An access check is made to establish whether the user has the > correct authorization to access the resource. If the access check passes, > the resource is then returned to the browser. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2018-02-28 12:30 GMT-03:00 Tim Tyler <[email protected]>: > > CAS Experts, > > Looking for any hints I can get. > > We are running CAS 5.2 on REdhat 7. I am trying to get SAML to work > with our Jenzabar JICS portal. Trying to Configure CAS as the Identity > Manager and Jenzabar as the Identity Provider. > > When one goes to our Jenzabar url to login, they simply need to click the > login icon. It redirects the user back to our CAS server. After > authenticating into CAS successfully, it never takes the user back to > Jenzabar. I am not sure what side to blame and I have never configured > SAML before. > > When configuring SAML 2.0 in the CAS-management, we do have the meta path > entered from Jenzabar and it does provide the following: > > <md:EntityDescriptor entityID="https://bcportaldev. > beloit.edu/ics/StaticPages/SAML/ServiceProvider/ACS.aspx"><md:SPSSODescriptor > protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0: > protocol"><md:NameIDFormat>urn:oasis:names:tc:SAML:2.0: > nameid-format:unspecified</md:NameIDFormat><md:AssertionConsumerService > isDefault="true" index="0" > Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" > Location="https://bcportaldev.beloit.edu/ics/StaticPages/ > SAML/ServiceProvider/ACS.aspx"/><md:AssertionConsumerService index="1" > Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location=" > https://bcportaldev.beloit.edu/ics/StaticPages/ > SAML/ServiceProvider/ACS.aspx"/></md:SPSSODescriptor></md: > EntityDescriptor> > > > > I have the following in cas.properties: > > # CAS SAML2.0 IDP > > > > cas.authn.samlIdp.entityId=https://cas.beloit.edu:8443/idp > > cas.authn.samlIdp.scope=cas.beloit.edu > > cas.authn.samlIdp.metadata.cacheExpirationMinutes=30 > > cas.authn.samlIdp.metadata.failFast=false > > cas.authn.samlIdp.metadata.location=file:/etc/cas/saml/ > > cas.authn.samlIdp.metadata.privateKeyAlgName=RSA > > cas.authn.samlIdp.metadata.requireValidMetadata=true > > cas.authn.samlIdp.logout.forceSignedLogoutRequests=true > > cas.authn.samlIdp.logout.singleLogoutCallbacksDisabled=false > > cas.authn.samlIdp.response.skewAllowance=0 > > cas.authn.samlIdp.response.signError=false > > cas.authn.samlIdp.response.useAttributeFriendlyName=true > > > > I do see the following in /etc/cas/saml self created by CAS. > > drwxr-xr-x 2 root root 128 Feb 20 10:40 id > > -rw-r--r-- 1 root root 1135 Feb 27 15:45 idp-encryption.crt > > -rw-r--r-- 1 root root 1679 Feb 27 15:45 idp-encryption.key > > -rw-r--r-- 1 root root 6938 Feb 27 15:49 idp-metadata.xml > > -rw-r--r-- 1 root root 1135 Feb 27 15:45 idp-signing.crt > > > > > > The following relates to our SAML json service for Jenzabar: > > > > [root@cas services]# more Jenzabar-1519156718058.json > > { > > @class: org.apereo.cas.support.saml.services.SamlRegisteredService > > serviceId: https://bcportaldev.beloit.edu.* > > name: Jenzabar > > id: 1519156718058 > > expirationPolicy: > > { > > @class: org.apereo.cas.services.DefaultRegisteredServiceExpira > tionPolicy > > deleteWhenExpired: false > > notifyWhenDeleted: false > > } > > proxyPolicy: > > { > > @class: org.apereo.cas.services.RefuseRegisteredServiceProxyPolicy > > } > > evaluationOrder: -1 > > usernameAttributeProvider: > > { > > @class: org.apereo.cas.services.DefaultRegisteredServiceUserna > meProvider > > canonicalizationMode: NONE > > encryptUsername: false > > } > > logoutType: BACK_CHANNEL > > attributeReleasePolicy: > > { > > @class: org.apereo.cas.services.ReturnAllowedAttributeReleasePolicy > > principalAttributesRepository: > > { > > @class: org.apereo.cas.authentication.principal. > DefaultPrincipalAttributes > > Repository > > expiration: 2 > > timeUnit: HOURS > > } > > consentPolicy: > > { > > @class: org.apereo.cas.services.consent. > DefaultRegisteredServiceConsentPol > > icy > > enabled: true > > } > > authorizedToReleaseCredentialPassword: false > > authorizedToReleaseProxyGrantingTicket: false > > excludeDefaultAttributes: false > > authorizedToReleaseAuthenticationAttributes: true > > } > > multifactorPolicy: > > { > > @class: org.apereo.cas.services.DefaultRegisteredServiceMultif > actorPolicy > > failureMode: NOT_SET > > bypassEnabled: false > > } > > accessStrategy: > > { > > @class: org.apereo.cas.services.DefaultRegisteredServiceAccessStrategy > > order: 0 > > enabled: true > > ssoEnabled: true > > requireAllAttributes: true > > caseInsensitive: false > > } > > metadataLocation: https://bcportaldev.beloit.edu/ICS/StaticPages/SAML/ > ServiceP > > rovider/Metadata.ashx > > metadataMaxValidity: 0 > > metadataExpirationDuration: PT60M > > signAssertions: true > > skipGeneratingAssertionNameId: false > > skipGeneratingSubjectConfirmationInResponseTo: false > > skipGeneratingSubjectConfirmationNotOnOrAfter: false > > skipGeneratingSubjectConfirmationRecipient: false > > skipGeneratingSubjectConfirmationNotBefore: true > > signResponses: true > > encryptAssertions: true > > metadataCriteriaRoles: SPSSODescriptor > > metadataCriteriaRemoveEmptyEntitiesDescriptors: true > > metadataCriteriaRemoveRolelessEntityDescriptors: true > > signingCredentialType: BASIC > > } > > > > So what reason(s) might I look for that might explain why CAS doesn't send > the user back to the Jenzabar portal? Could this be a problem with the > metadata? Missing something on CAS? > > > > > > > > Tim Tyler > > Network Engineer > > Beloit College > > > > -- > - 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 [email protected]. > To view this discussion on the web visit https://groups.google.com/a/ > apereo.org/d/msgid/cas-user/5c9b1eaee8f062c762524384f90b87 > 90%40mail.gmail.com > <https://groups.google.com/a/apereo.org/d/msgid/cas-user/5c9b1eaee8f062c762524384f90b8790%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > > > -- > - 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 [email protected]. > To view this discussion on the web visit https://groups.google.com/a/ > apereo.org/d/msgid/cas-user/CAMY5mifR%2BWSTW5kpOf0g2bjC4P% > 3D%2BSeLQE3AaW6Fd%3D%3DEXiNBS7Q%40mail.gmail.com > <https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAMY5mifR%2BWSTW5kpOf0g2bjC4P%3D%2BSeLQE3AaW6Fd%3D%3DEXiNBS7Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- > - 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 [email protected]. > To view this discussion on the web visit https://groups.google.com/a/ > apereo.org/d/msgid/cas-user/f34ad1646941d5181a6f2162db48e3 > f0%40mail.gmail.com > <https://groups.google.com/a/apereo.org/d/msgid/cas-user/f34ad1646941d5181a6f2162db48e3f0%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- - 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAMY5midH-sQjGFfyk1mitMKWJyUbec%2B2Ybm1bnQSYtmS1Fi-GQ%40mail.gmail.com.
