SAML and Jenzabar JICS

[Tim Tyler]

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

 

[Man H]

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#">...</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#">...</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#">...</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">

us...@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#">...</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#">...</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#">...</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">

us...@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.

--
- 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+unsubscribe@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.

[Tim Tyler]

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-...@apereo.org [mailto:cas-...@apereo.org] On Behalf Of Man H
Sent: Wednesday, February 28, 2018 10:24 AM
To: cas-...@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#">...</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.

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#">...</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.

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.

 

 

 

 

 

 

--

To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@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.

 

--

- 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+u...@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.

[Man H]

read point 2 of previously attached flow.

--

To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscribe@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.

--
- 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+unsubscribe@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.

--

- 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+unsubscribe@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.