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:* cas-user@apereo.org [mailto:cas-user@apereo.org] *On Behalf Of *Man H *Sent:* Wednesday, February 28, 2018 10:24 AM *To:* cas-user@apereo.org *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"> u...@mail.example.org </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"> u...@mail.example.org </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 <ty...@beloit.edu>: 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.DefaultRegisteredServiceExpirationPolicy deleteWhenExpired: false notifyWhenDeleted: false } proxyPolicy: { @class: org.apereo.cas.services.RefuseRegisteredServiceProxyPolicy } evaluationOrder: -1 usernameAttributeProvider: { @class: org.apereo.cas.services.DefaultRegisteredServiceUsernameProvider 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.DefaultRegisteredServiceMultifactorPolicy 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 cas-user+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/5c9b1eaee8f062c762524384f90b8790%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 cas-user+unsubscr...@apereo.org. 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 cas-user+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/f34ad1646941d5181a6f2162db48e3f0%40mail.gmail.com.
