[Architecture] SAML Artifact Binding - Server Side Implementations

[Vihanga Liyanage]

Hi all,

I've started working on the server-side implementation of SAML Artifact
Binding. The basic idea is as follows.

When authentication is done via SAML, SAML assertion is sent to the user
agent (browser) as a direct response from the IDP. One disadvantage of this
method is the possibility of communication messages being intersepted at
the browser. Also, there could be limitations on browsers such as limits on
query string / POST payload sizes, no support for JavaScript, etc. To
overcome these problems, SAML Artifact Binding has been introduced.

When the user is authenticated, the IDP responds with a key known as
SAMLart, which will be then sent to the service provider by the browser.
Then the SP uses this key to request the actual SAML assertion from the IDP
via a back channel call. This method reduces the use of browsers compared
to the old method. Below diagram shows the request flow with SAML Artifact
Binding.

[image: image.png]

​Currently the client side implementations have been completed and
discussed here [1]. The goal of this project is to implement the necessary
backend components following the official SAML specification [2]

.

I highly appriciate your valuable concerns and input on this.

Best regards,
Vihanga.

[1] - "[Architecture] [IAM] SAML Artifact Binding" @ architecture@wso2.org
[2] -
https://www.oasis-open.org/committees/download.php/35387/sstc-saml-bindings-errata-2.0-wd-05-diff.pdf

-- 

Vihanga Liyanage

Software Engineer | WS*O₂* Inc.

M : +*94710124103* | http://wso2.com

[image: http://wso2.com/signature] 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] SAML Artifact Binding - Server Side Implementations

[Vihanga Liyanage]

Hi all,

As I'm going through the specifications, I came across following problems.

   - The above diagram shows Login Response binding with SAML art. There
   are other aspects of this as well such as Login Request Binding, Logout
   Request Binding, etc. Below diagram shows both login request and response
   bound with SAML art.

[image: image.png]
   Question is, which should we do first. I think login
response binding is better, to begin with.

   - IDP has to store a reference to the artifact so that it can respond
   with the SAML assertion to the SP. We can either generate the assertion and
   store it completely in the database and send that, or we can generate and
   send the assertion once the artifact is received. What should be the best
   method?
   - Should we keep a status about the artifact and assertion in our DB? If
   yes, what are the use cases?
   - What should happen if an artifact is sent again by someone after the
   assertion is issued? The spec says the following but I didn't see any
   specific instruction on what to do.
   - *"It is RECOMMENDED that artifact receivers also enforce a single-use
  semantic on the artifact values they receive, to prevent an attacker from
  interfering with the resolution of an artifact by a user agent and then
  re-submitting it to the artifact receiver. If an attempt to resolve an
  artifact does not complete successfully, the artifact SHOULD be
placed into
  a blocked artifact list for a period of time that exceeds a reasonable
  acceptance period during which the artifact issuer would resolve the
  artifact."*

Please let me know your thoughts on the above.

Regards,
Vihanga.

On Wed, Jun 20, 2018 at 10:28 AM Vihanga Liyanage  wrote:

> Hi all,
>
> I've started working on the server-side implementation of SAML Artifact
> Binding. The basic idea is as follows.
>
> When authentication is done via SAML, SAML assertion is sent to the user
> agent (browser) as a direct response from the IDP. One disadvantage of this
> method is the possibility of communication messages being intersepted at
> the browser. Also, there could be limitations on browsers such as limits on
> query string / POST payload sizes, no support for JavaScript, etc. To
> overcome these problems, SAML Artifact Binding has been introduced.
>
> When the user is authenticated, the IDP responds with a key known as
> SAMLart, which will be then sent to the service provider by the browser.
> Then the SP uses this key to request the actual SAML assertion from the IDP
> via a back channel call. This method reduces the use of browsers compared
> to the old method. Below diagram shows the request flow with SAML Artifact
> Binding.
>
> [image: image.png]
>
> ​Currently the client side implementations have been completed and
> discussed here [1]. The goal of this project is to implement the necessary
> backend components following the official SAML specification [2]
> 
> .
>
> I highly appriciate your valuable concerns and input on this.
>
> Best regards,
> Vihanga.
>
> [1] - "[Architecture] [IAM] SAML Artifact Binding" @ architecture@wso2.org
> [2] -
> https://www.oasis-open.org/committees/download.php/35387/sstc-saml-bindings-errata-2.0-wd-05-diff.pdf
> 
> --
>
> Vihanga Liyanage
>
> Software Engineer | WS*O₂* Inc.
>
> M : +*94710124103* | http://wso2.com
>
> [image: http://wso2.com/signature] 
>


-- 

Vihanga Liyanage

Software Engineer | WS*O₂* Inc.

M : +*94710124103* | http://wso2.com

[image: http://wso2.com/signature] 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] SAML Artifact Binding - Server Side Implementations

[Vihanga Liyanage]

[+ Dev]

On Fri, Jun 22, 2018 at 3:23 PM Vihanga Liyanage  wrote:

> Hi all,
>
> As I'm going through the specifications, I came across following problems.
>
>- The above diagram shows Login Response binding with SAML art. There
>are other aspects of this as well such as Login Request Binding, Logout
>Request Binding, etc. Below diagram shows both login request and response
>bound with SAML art.
>
> [image: image.png]
>Question is, which should we do first. I think login
> response binding is better, to begin with.
>
>- IDP has to store a reference to the artifact so that it can respond
>with the SAML assertion to the SP. We can either generate the assertion and
>store it completely in the database and send that, or we can generate and
>send the assertion once the artifact is received. What should be the best
>method?
>- Should we keep a status about the artifact and assertion in our DB?
>If yes, what are the use cases?
>- What should happen if an artifact is sent again by someone after the
>assertion is issued? The spec says the following but I didn't see any
>specific instruction on what to do.
>- *"It is RECOMMENDED that artifact receivers also enforce a
>   single-use semantic on the artifact values they receive, to prevent an
>   attacker from interfering with the resolution of an artifact by a user
>   agent and then re-submitting it to the artifact receiver. If an attempt 
> to
>   resolve an artifact does not complete successfully, the artifact SHOULD 
> be
>   placed into a blocked artifact list for a period of time that exceeds a
>   reasonable acceptance period during which the artifact issuer would 
> resolve
>   the artifact."*
>
> Please let me know your thoughts on the above.
>
> Regards,
> Vihanga.
>
> On Wed, Jun 20, 2018 at 10:28 AM Vihanga Liyanage 
> wrote:
>
>> Hi all,
>>
>> I've started working on the server-side implementation of SAML Artifact
>> Binding. The basic idea is as follows.
>>
>> When authentication is done via SAML, SAML assertion is sent to the user
>> agent (browser) as a direct response from the IDP. One disadvantage of this
>> method is the possibility of communication messages being intersepted at
>> the browser. Also, there could be limitations on browsers such as limits on
>> query string / POST payload sizes, no support for JavaScript, etc. To
>> overcome these problems, SAML Artifact Binding has been introduced.
>>
>> When the user is authenticated, the IDP responds with a key known as
>> SAMLart, which will be then sent to the service provider by the browser.
>> Then the SP uses this key to request the actual SAML assertion from the IDP
>> via a back channel call. This method reduces the use of browsers compared
>> to the old method. Below diagram shows the request flow with SAML Artifact
>> Binding.
>>
>> [image: image.png]
>>
>> ​Currently the client side implementations have been completed and
>> discussed here [1]. The goal of this project is to implement the necessary
>> backend components following the official SAML specification [2]
>> 
>> .
>>
>> I highly appriciate your valuable concerns and input on this.
>>
>> Best regards,
>> Vihanga.
>>
>> [1] - "[Architecture] [IAM] SAML Artifact Binding" @
>> architecture@wso2.org
>> [2] -
>> https://www.oasis-open.org/committees/download.php/35387/sstc-saml-bindings-errata-2.0-wd-05-diff.pdf
>> 
>> --
>>
>> Vihanga Liyanage
>>
>> Software Engineer | WS*O₂* Inc.
>>
>> M : +*94710124103* | http://wso2.com
>>
>> [image: http://wso2.com/signature] 
>>
>
>
> --
>
> Vihanga Liyanage
>
> Software Engineer | WS*O₂* Inc.
>
> M : +*94710124103* | http://wso2.com
>
> [image: http://wso2.com/signature] 
>


-- 

Vihanga Liyanage

Software Engineer | WS*O₂* Inc.

M : +*94710124103* | http://wso2.com

[image: http://wso2.com/signature] 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] SAML Artifact Binding - Server Side Implementations

[Vihanga Liyanage]

Hi all,

As for the discussion we had earlier [1], here attached the initial table
design to store the SAML assertions against the artifact ID. Please let me
know your concerns regarding this or anything discussed earlier.

[image: image.png]

[1] - "Invitation: [Architecture Review] - SAML Artifact Binding" @
engineering

On Fri, Jun 22, 2018 at 4:38 PM Vihanga Liyanage  wrote:

> [+ Dev]
>
> On Fri, Jun 22, 2018 at 3:23 PM Vihanga Liyanage  wrote:
>
>> Hi all,
>>
>> As I'm going through the specifications, I came across following problems.
>>
>>- The above diagram shows Login Response binding with SAML art. There
>>are other aspects of this as well such as Login Request Binding, Logout
>>Request Binding, etc. Below diagram shows both login request and response
>>bound with SAML art.
>>
>> [image: image.png]
>>Question is, which should we do first. I think login
>> response binding is better, to begin with.
>>
>>- IDP has to store a reference to the artifact so that it can respond
>>with the SAML assertion to the SP. We can either generate the assertion 
>> and
>>store it completely in the database and send that, or we can generate and
>>send the assertion once the artifact is received. What should be the best
>>method?
>>- Should we keep a status about the artifact and assertion in our DB?
>>If yes, what are the use cases?
>>- What should happen if an artifact is sent again by someone after
>>the assertion is issued? The spec says the following but I didn't see any
>>specific instruction on what to do.
>>- *"It is RECOMMENDED that artifact receivers also enforce a
>>   single-use semantic on the artifact values they receive, to prevent an
>>   attacker from interfering with the resolution of an artifact by a user
>>   agent and then re-submitting it to the artifact receiver. If an 
>> attempt to
>>   resolve an artifact does not complete successfully, the artifact 
>> SHOULD be
>>   placed into a blocked artifact list for a period of time that exceeds a
>>   reasonable acceptance period during which the artifact issuer would 
>> resolve
>>   the artifact."*
>>
>> Please let me know your thoughts on the above.
>>
>> Regards,
>> Vihanga.
>>
>> On Wed, Jun 20, 2018 at 10:28 AM Vihanga Liyanage 
>> wrote:
>>
>>> Hi all,
>>>
>>> I've started working on the server-side implementation of SAML Artifact
>>> Binding. The basic idea is as follows.
>>>
>>> When authentication is done via SAML, SAML assertion is sent to the user
>>> agent (browser) as a direct response from the IDP. One disadvantage of this
>>> method is the possibility of communication messages being intersepted at
>>> the browser. Also, there could be limitations on browsers such as limits on
>>> query string / POST payload sizes, no support for JavaScript, etc. To
>>> overcome these problems, SAML Artifact Binding has been introduced.
>>>
>>> When the user is authenticated, the IDP responds with a key known as
>>> SAMLart, which will be then sent to the service provider by the browser.
>>> Then the SP uses this key to request the actual SAML assertion from the IDP
>>> via a back channel call. This method reduces the use of browsers compared
>>> to the old method. Below diagram shows the request flow with SAML Artifact
>>> Binding.
>>>
>>> [image: image.png]
>>>
>>> ​Currently the client side implementations have been completed and
>>> discussed here [1]. The goal of this project is to implement the necessary
>>> backend components following the official SAML specification [2]
>>> 
>>> .
>>>
>>> I highly appriciate your valuable concerns and input on this.
>>>
>>> Best regards,
>>> Vihanga.
>>>
>>> [1] - "[Architecture] [IAM] SAML Artifact Binding" @
>>> architecture@wso2.org
>>> [2] -
>>> https://www.oasis-open.org/committees/download.php/35387/sstc-saml-bindings-errata-2.0-wd-05-diff.pdf
>>> 
>>> --
>>>
>>> Vihanga Liyanage
>>>
>>> Software Engineer | WS*O₂* Inc.
>>>
>>> M : +*94710124103* | http://wso2.com
>>>
>>> [image: http://wso2.com/signature] 
>>>
>>
>>
>> --
>>
>> Vihanga Liyanage
>>
>> Software Engineer | WS*O₂* Inc.
>>
>> M : +*94710124103* | http://wso2.com
>>
>> [image: http://wso2.com/signature] 
>>
>
>
> --
>
> Vihanga Liyanage
>
> Software Engineer | WS*O₂* Inc.
>
> M : +*94710124103* | http://wso2.com
>
> [image: http://wso2.com/signature] 
>


-- 

Vihanga Liyanage

Software Engineer | WS*O₂* Inc.

M : +*94710124103* | http://wso2.com

[image: http://wso2.com/signature] 
_

Re: [Architecture] SAML Artifact Binding - Server Side Implementations

[Farasath Ahamed]

On Mon, Jul 2, 2018 at 2:48 PM, Vihanga Liyanage  wrote:

> Hi all,
>
> As for the discussion we had earlier [1], here attached the initial table
> design to store the SAML assertions against the artifact ID. Please let me
> know your concerns regarding this or anything discussed earlier.
>
> [image: image.png]
>

SAML Assertion size is going to depend with the number of requested claims,
signing, encryption etc. How are we planning to handle this?

>
> [1] - "Invitation: [Architecture Review] - SAML Artifact Binding" @
> engineering
>
> On Fri, Jun 22, 2018 at 4:38 PM Vihanga Liyanage  wrote:
>
>> [+ Dev]
>>
>> On Fri, Jun 22, 2018 at 3:23 PM Vihanga Liyanage 
>> wrote:
>>
>>> Hi all,
>>>
>>> As I'm going through the specifications, I came across following
>>> problems.
>>>
>>>- The above diagram shows Login Response binding with SAML art.
>>>There are other aspects of this as well such as Login Request Binding,
>>>Logout Request Binding, etc. Below diagram shows both login request and
>>>response bound with SAML art.
>>>
>>> [image: image.png]
>>>Question is, which should we do first. I think login
>>> response binding is better, to begin with.
>>>
>>>- IDP has to store a reference to the artifact so that it can
>>>respond with the SAML assertion to the SP. We can either generate the
>>>assertion and store it completely in the database and send that, or we 
>>> can
>>>generate and send the assertion once the artifact is received. What 
>>> should
>>>be the best method?
>>>- Should we keep a status about the artifact and assertion in our
>>>DB? If yes, what are the use cases?
>>>- What should happen if an artifact is sent again by someone after
>>>the assertion is issued? The spec says the following but I didn't see any
>>>specific instruction on what to do.
>>>- *"It is RECOMMENDED that artifact receivers also enforce a
>>>   single-use semantic on the artifact values they receive, to prevent an
>>>   attacker from interfering with the resolution of an artifact by a user
>>>   agent and then re-submitting it to the artifact receiver. If an 
>>> attempt to
>>>   resolve an artifact does not complete successfully, the artifact 
>>> SHOULD be
>>>   placed into a blocked artifact list for a period of time that exceeds 
>>> a
>>>   reasonable acceptance period during which the artifact issuer would 
>>> resolve
>>>   the artifact."*
>>>
>>> Please let me know your thoughts on the above.
>>>
>>> Regards,
>>> Vihanga.
>>>
>>> On Wed, Jun 20, 2018 at 10:28 AM Vihanga Liyanage 
>>> wrote:
>>>
 Hi all,

 I've started working on the server-side implementation of SAML Artifact
 Binding. The basic idea is as follows.

 When authentication is done via SAML, SAML assertion is sent to the
 user agent (browser) as a direct response from the IDP. One disadvantage of
 this method is the possibility of communication messages being intersepted
 at the browser. Also, there could be limitations on browsers such as limits
 on query string / POST payload sizes, no support for JavaScript, etc. To
 overcome these problems, SAML Artifact Binding has been introduced.

 When the user is authenticated, the IDP responds with a key known as
 SAMLart, which will be then sent to the service provider by the browser.
 Then the SP uses this key to request the actual SAML assertion from the IDP
 via a back channel call. This method reduces the use of browsers compared
 to the old method. Below diagram shows the request flow with SAML Artifact
 Binding.

 [image: image.png]

 ​Currently the client side implementations have been completed and
 discussed here [1]. The goal of this project is to implement the necessary
 backend components following the official SAML specification [2]
 
 .

 I highly appriciate your valuable concerns and input on this.

 Best regards,
 Vihanga.

 [1] - "[Architecture] [IAM] SAML Artifact Binding" @
 architecture@wso2.org
 [2] - https://www.oasis-open.org/committees/download.php/35387/
 sstc-saml-bindings-errata-2.0-wd-05-diff.pdf
 
 --

 Vihanga Liyanage

 Software Engineer | WS*O₂* Inc.

 M : +*94710124103* | http://wso2.com

 [image: http://wso2.com/signature] 

>>>
>>>
>>> --
>>>
>>> Vihanga Liyanage
>>>
>>> Software Engineer | WS*O₂* Inc.
>>>
>>> M : +*94710124103* | http://wso2.com
>>>
>>> [image: http://wso2.com/signature] 
>>>
>>
>>
>> --
>>
>> Vihanga Liyan

Re: [Architecture] SAML Artifact Binding - Server Side Implementations

[Vihanga Liyanage]

Hi Farasath,

>
> SAML Assertion size is going to depend with the number of requested
> claims, signing, encryption etc. How are we planning to handle this
> ​?
>

​That is a valid question! The initial value, 4096 was used in the
IDN_SAML2_ASSERTION_STORE table. But with my implementation, later I found
out that it's not enough and used 5120 for now. ​Is there a maximum size
that we can decide on?

> ​
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] SAML Artifact Binding - Server Side Implementations

[Maduranga Siriwardena]

Databases can handle large text fields. Column type depends on the
database. For example [1] shows few MySql column types that can handle
large texts.

And in the same time there are some database column types that can handle
xml etc. You will need to do some research to to find suitable column type
for your requirement.

[1]
https://stackoverflow.com/questions/6766781/maximum-length-for-mysql-type-text

Thanks,

On Tue, Jul 3, 2018 at 12:26 PM Vihanga Liyanage  wrote:

> Hi Farasath,
>
>>
>> SAML Assertion size is going to depend with the number of requested
>> claims, signing, encryption etc. How are we planning to handle this
>> ​?
>>
>
> ​That is a valid question! The initial value, 4096 was used in the
> IDN_SAML2_ASSERTION_STORE table. But with my implementation, later I found
> out that it's not enough and used 5120 for now. ​Is there a maximum size
> that we can decide on?
>
>> ​
>>
>>
>

-- 
Maduranga Siriwardena
Senior Software Engineer
WSO2 Inc; http://wso2.com/

Email: madura...@wso2.com
Mobile: +94718990591
Blog: *https://madurangasiriwardena.wordpress.com/
*

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] SAML Artifact Binding - Server Side Implementations

[Vihanga Liyanage]

Hi all,

In the discussion we had today, a concern was raised about storing SAML
assertions in the database as it can become quite large. The alternatives
proposed are as follows.

   1. Store any information we need to build the SAML assertion at artifact
   resolution time and build it there.


   - AFAIU, we need following data to be stored in the database to go with
  this approach.
 - Attributes in SAMLSSOAuthnReqDTO object.


   - AuthenticatedUser
   - NameIDFormat
   - assertionConsumerURL
   - idPInitSSOEnabled
   - AuthnReq ID
   - requestedRecipients list
   - IdpAuthenticationContextProperties
   - Issuer
   - RequestedAttributes list
   - IssuerWithDomain
   - RequestedAudiences list
   - SigningAlgorithmUri
   - DigestAlgorithmUri


   - Timestamp
 - Session ID


   1. Build the assertion without signature data, which will reduce the
   size. We can add the signature information at artifact resolution.


   - For this approach, we need following data to be stored in the database
  apart from the built assertion.
 - Attributes in SAMLSSOAuthnReqDTO object.


   - SigningAlgorithmUri
   - DigestAlgorithmUri
   - AuthenticatedUser

Currently, I have implemented to store and retrieve complete SAML assertion
as we decided earlier. AFAIU, option two would be better since option one
requires complex data to be stored in the DB. Please let me know your
thoughts on this.

Also, do note following.

   - I couldn't find anything in the specifications that suggest or oppose
   doing any of these. (Please correct me if I'm wrong) Therefore, we have the
   freedom do what we see as best.
   - We don't execute search functions in the DB using assertions.

Best Regards,
Vihanga.

On Tue, Jul 3, 2018 at 1:48 PM Maduranga Siriwardena 
wrote:

> Databases can handle large text fields. Column type depends on the
> database. For example [1] shows few MySql column types that can handle
> large texts.
>
> And in the same time there are some database column types that can handle
> xml etc. You will need to do some research to to find suitable column type
> for your requirement.
>
> [1]
> https://stackoverflow.com/questions/6766781/maximum-length-for-mysql-type-text
>
> Thanks,
>
> On Tue, Jul 3, 2018 at 12:26 PM Vihanga Liyanage  wrote:
>
>> Hi Farasath,
>>
>>>
>>> SAML Assertion size is going to depend with the number of requested
>>> claims, signing, encryption etc. How are we planning to handle this
>>> ​?
>>>
>>
>> ​That is a valid question! The initial value, 4096 was used in the
>> IDN_SAML2_ASSERTION_STORE table. But with my implementation, later I found
>> out that it's not enough and used 5120 for now. ​Is there a maximum size
>> that we can decide on?
>>
>>> ​
>>>
>>>
>>
>
> --
> Maduranga Siriwardena
> Senior Software Engineer
> WSO2 Inc; http://wso2.com/
>
> Email: madura...@wso2.com
> Mobile: +94718990591
> Blog: *https://madurangasiriwardena.wordpress.com/
> *
> 
>


-- 

Vihanga Liyanage

Software Engineer | WS*O₂* Inc.

M : +*94710124103* | http://wso2.com

[image: http://wso2.com/signature] 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] SAML Artifact Binding - Server Side Implementations

[Ruwan Abeykoon]

Hi Vihanga,
In data storage theory, we have to store each atomic value in specific
field. Now we have to decide what are our atomic values.

e.g. is "AuthnRq ID" has a significance on its own? do we need to search
for "AuthnRq ID"? do we want to change "AuthnRq ID"? etc. If yes, then it
is an atomic value and need to go to its own field in database. Then we
need to construct the assertion upon request with all component data.

+1 on generating signature when we generate the response. In-fact we should
generate anything possible at the response generation time with all
available component data.

Cheers,
Ruwan


On Wed, Jul 4, 2018 at 9:13 PM Vihanga Liyanage  wrote:

> Hi all,
>
> In the discussion we had today, a concern was raised about storing SAML
> assertions in the database as it can become quite large. The alternatives
> proposed are as follows.
>
>1. Store any information we need to build the SAML assertion at
>artifact resolution time and build it there.
>
>
>- AFAIU, we need following data to be stored in the database to go
>   with this approach.
>  - Attributes in SAMLSSOAuthnReqDTO object.
>
>
>- AuthenticatedUser
>- NameIDFormat
>- assertionConsumerURL
>- idPInitSSOEnabled
>- AuthnReq ID
>- requestedRecipients list
>- IdpAuthenticationContextProperties
>- Issuer
>- RequestedAttributes list
>- IssuerWithDomain
>- RequestedAudiences list
>- SigningAlgorithmUri
>- DigestAlgorithmUri
>
>
>- Timestamp
>  - Session ID
>
>
>1. Build the assertion without signature data, which will reduce the
>size. We can add the signature information at artifact resolution.
>
>
>- For this approach, we need following data to be stored in the
>   database apart from the built assertion.
>  - Attributes in SAMLSSOAuthnReqDTO object.
>
>
>- SigningAlgorithmUri
>- DigestAlgorithmUri
>- AuthenticatedUser
>
> Currently, I have implemented to store and retrieve complete SAML
> assertion as we decided earlier. AFAIU, option two would be better since
> option one requires complex data to be stored in the DB. Please let me know
> your thoughts on this.
>
> Also, do note following.
>
>- I couldn't find anything in the specifications that suggest or
>oppose doing any of these. (Please correct me if I'm wrong) Therefore, we
>have the freedom do what we see as best.
>- We don't execute search functions in the DB using assertions.
>
> Best Regards,
> Vihanga.
>
> On Tue, Jul 3, 2018 at 1:48 PM Maduranga Siriwardena 
> wrote:
>
>> Databases can handle large text fields. Column type depends on the
>> database. For example [1] shows few MySql column types that can handle
>> large texts.
>>
>> And in the same time there are some database column types that can handle
>> xml etc. You will need to do some research to to find suitable column type
>> for your requirement.
>>
>> [1]
>> https://stackoverflow.com/questions/6766781/maximum-length-for-mysql-type-text
>>
>> Thanks,
>>
>> On Tue, Jul 3, 2018 at 12:26 PM Vihanga Liyanage 
>> wrote:
>>
>>> Hi Farasath,
>>>

 SAML Assertion size is going to depend with the number of requested
 claims, signing, encryption etc. How are we planning to handle this
 ​?

>>>
>>> ​That is a valid question! The initial value, 4096 was used in the
>>> IDN_SAML2_ASSERTION_STORE table. But with my implementation, later I found
>>> out that it's not enough and used 5120 for now. ​Is there a maximum size
>>> that we can decide on?
>>>
 ​


>>>
>>
>> --
>> Maduranga Siriwardena
>> Senior Software Engineer
>> WSO2 Inc; http://wso2.com/
>>
>> Email: madura...@wso2.com
>> Mobile: +94718990591
>> Blog: *https://madurangasiriwardena.wordpress.com/
>> *
>> 
>>
>
>
> --
>
> Vihanga Liyanage
>
> Software Engineer | WS*O₂* Inc.
>
> M : +*94710124103* | http://wso2.com
>
> [image: http://wso2.com/signature] 
>


-- 

*Ruwan Abeykoon*
*Associate Director/Architect**,*
*WSO2, Inc. http://wso2.com  *
*lean.enterprise.middleware.*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] SAML Artifact Binding - Server Side Implementations

[Malithi Edirisinghe]

On Wed, Jul 4, 2018 at 9:13 PM, Vihanga Liyanage  wrote:

> Hi all,
>
> In the discussion we had today, a concern was raised about storing SAML
> assertions in the database as it can become quite large. The alternatives
> proposed are as follows.
>
>1. Store any information we need to build the SAML assertion at
>artifact resolution time and build it there.
>
>
>- AFAIU, we need following data to be stored in the database to go
>   with this approach.
>  - Attributes in SAMLSSOAuthnReqDTO object.
>
>
>- AuthenticatedUser
>- NameIDFormat
>- assertionConsumerURL
>- idPInitSSOEnabled
>- AuthnReq ID
>- requestedRecipients list
>- IdpAuthenticationContextProperties
>- Issuer
>- RequestedAttributes list
>- IssuerWithDomain
>- RequestedAudiences list
>- SigningAlgorithmUri
>- DigestAlgorithmUri
>
>
>- Timestamp
>  - Session ID
>
>
>1. Build the assertion without signature data, which will reduce the
>size. We can add the signature information at artifact resolution.
>
>
>- For this approach, we need following data to be stored in the
>   database apart from the built assertion.
>  - Attributes in SAMLSSOAuthnReqDTO object.
>
>
>- SigningAlgorithmUri
>- DigestAlgorithmUri
>- AuthenticatedUser
>
> Basically, algorithms can be identified by the SP.
When the artifact resolving request comes if we can resolve the SP we could
pick up the algorithms. I don't see a necessity of the authenticated user
here, but the tenant domain.
So we should be able to resolve the tenant domain from the artifact.


> Currently, I have implemented to store and retrieve complete SAML
> assertion as we decided earlier. AFAIU, option two would be better since
> option one requires complex data to be stored in the DB. Please let me know
> your thoughts on this.
>

As Ruwan had mentioned you will have to think of the significance of each
property/param that you mentioned above to decide on the model.

As I see we don't need to store all you mentioned above under (1) and build
the assertion later. But I see authenticated subject, authentication
request id as some significant attributes on any requirements to query the
assertion. Moreover, at the time the artifact response goes to SP, the user
is authenticated and the SAML assertion is the identity of that user. So I
don't see there would be anything that will impact on the generated
assertion when resolving the artifact and in returning the assertion.
Thus, I would opt for option 2.

Better if you can have a look at the Assertion query profile as well. We
should be persisting the SAML assertion there as well or some structure to
query the assertion.
May be that implementation can be reused.

@Omindu ,
May be you can give more insight on query profile and see if we can relate
with it's implementation in this context.



> Also, do note following.
>
>- I couldn't find anything in the specifications that suggest or
>oppose doing any of these. (Please correct me if I'm wrong) Therefore, we
>have the freedom do what we see as best.
>- We don't execute search functions in the DB using assertions.
>
> Best Regards,
> Vihanga.
>
> On Tue, Jul 3, 2018 at 1:48 PM Maduranga Siriwardena 
> wrote:
>
>> Databases can handle large text fields. Column type depends on the
>> database. For example [1] shows few MySql column types that can handle
>> large texts.
>>
>> And in the same time there are some database column types that can handle
>> xml etc. You will need to do some research to to find suitable column type
>> for your requirement.
>>
>> [1] https://stackoverflow.com/questions/6766781/maximum-
>> length-for-mysql-type-text
>>
>> Thanks,
>>
>> On Tue, Jul 3, 2018 at 12:26 PM Vihanga Liyanage 
>> wrote:
>>
>>> Hi Farasath,
>>>

 SAML Assertion size is going to depend with the number of requested
 claims, signing, encryption etc. How are we planning to handle this
 ​?

>>>
>>> ​That is a valid question! The initial value, 4096 was used in the
>>> IDN_SAML2_ASSERTION_STORE table. But with my implementation, later I found
>>> out that it's not enough and used 5120 for now. ​Is there a maximum size
>>> that we can decide on?
>>>
 ​


>>>
>>
>> --
>> Maduranga Siriwardena
>> Senior Software Engineer
>> WSO2 Inc; http://wso2.com/
>>
>> Email: madura...@wso2.com
>> Mobile: +94718990591
>> Blog: *https://madurangasiriwardena.wordpress.com/
>> *
>> 
>>
>
>
> --
>
> Vihanga Liyanage
>
> Software Engineer | WS*O₂* Inc.
>
> M : +*94710124103* | http://wso2.com
>
> [image: http://wso2.com/signature] 
>

Thanks,
Malithi.

-- 

*Malithi Edirisinghe*
Associate Technical Lead
WSO2 Inc.

Mobile : +94 (0) 718176807
malit...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/m

Re: [Architecture] SAML Artifact Binding - Server Side Implementations

[Vihanga Liyanage]

Hi all,

With the discussion we had today, we have decided to go with below database
structure.

IDN_SAML2_ARTIFACT_STORE
PK ID INT NOT NULL

SOURCE_ID BLOB NOT NULL

MESSAGE_HANDLER BLOB NOT NULL

AUTHN_REQ_DTO BLOB NOT NULL

SESSION_ID VARCHAR(255) NOT NULL

INTI_TIMESTAMP DATETIME NOT NULL

EXP_TIMESTAMP DATETIME NOT NULL

We'll build the SAML assertion as well as the response object at artifact
resolution time. Please let me know your concerns on this.

Best regards,
Vihanga.

On Thu, Jul 5, 2018 at 8:12 AM Malithi Edirisinghe 
wrote:

>
>
> On Wed, Jul 4, 2018 at 9:13 PM, Vihanga Liyanage  wrote:
>
>> Hi all,
>>
>> In the discussion we had today, a concern was raised about storing SAML
>> assertions in the database as it can become quite large. The alternatives
>> proposed are as follows.
>>
>>1. Store any information we need to build the SAML assertion at
>>artifact resolution time and build it there.
>>
>>
>>- AFAIU, we need following data to be stored in the database to go
>>   with this approach.
>>  - Attributes in SAMLSSOAuthnReqDTO object.
>>
>>
>>- AuthenticatedUser
>>- NameIDFormat
>>- assertionConsumerURL
>>- idPInitSSOEnabled
>>- AuthnReq ID
>>- requestedRecipients list
>>- IdpAuthenticationContextProperties
>>- Issuer
>>- RequestedAttributes list
>>- IssuerWithDomain
>>- RequestedAudiences list
>>- SigningAlgorithmUri
>>- DigestAlgorithmUri
>>
>>
>>- Timestamp
>>  - Session ID
>>
>>
>>1. Build the assertion without signature data, which will reduce the
>>size. We can add the signature information at artifact resolution.
>>
>>
>>- For this approach, we need following data to be stored in the
>>   database apart from the built assertion.
>>  - Attributes in SAMLSSOAuthnReqDTO object.
>>
>>
>>- SigningAlgorithmUri
>>- DigestAlgorithmUri
>>- AuthenticatedUser
>>
>> Basically, algorithms can be identified by the SP.
> When the artifact resolving request comes if we can resolve the SP we
> could pick up the algorithms. I don't see a necessity of the authenticated
> user here, but the tenant domain.
> So we should be able to resolve the tenant domain from the artifact.
>
>
>> Currently, I have implemented to store and retrieve complete SAML
>> assertion as we decided earlier. AFAIU, option two would be better since
>> option one requires complex data to be stored in the DB. Please let me know
>> your thoughts on this.
>>
>
> As Ruwan had mentioned you will have to think of the significance of each
> property/param that you mentioned above to decide on the model.
>
> As I see we don't need to store all you mentioned above under (1) and
> build the assertion later. But I see authenticated subject, authentication
> request id as some significant attributes on any requirements to query the
> assertion. Moreover, at the time the artifact response goes to SP, the user
> is authenticated and the SAML assertion is the identity of that user. So I
> don't see there would be anything that will impact on the generated
> assertion when resolving the artifact and in returning the assertion.
> Thus, I would opt for option 2.
>
> Better if you can have a look at the Assertion query profile as well. We
> should be persisting the SAML assertion there as well or some structure to
> query the assertion.
> May be that implementation can be reused.
>
> @Omindu ,
> May be you can give more insight on query profile and see if we can relate
> with it's implementation in this context.
>
>
>
>> Also, do note following.
>>
>>- I couldn't find anything in the specifications that suggest or
>>oppose doing any of these. (Please correct me if I'm wrong) Therefore, we
>>have the freedom do what we see as best.
>>- We don't execute search functions in the DB using assertions.
>>
>> Best Regards,
>> Vihanga.
>>
>> On Tue, Jul 3, 2018 at 1:48 PM Maduranga Siriwardena 
>> wrote:
>>
>>> Databases can handle large text fields. Column type depends on the
>>> database. For example [1] shows few MySql column types that can handle
>>> large texts.
>>>
>>> And in the same time there are some database column types that can
>>> handle xml etc. You will need to do some research to to find suitable
>>> column type for your requirement.
>>>
>>> [1]
>>> https://stackoverflow.com/questions/6766781/maximum-length-for-mysql-type-text
>>>
>>> Thanks,
>>>
>>> On Tue, Jul 3, 2018 at 12:26 PM Vihanga Liyanage 
>>> wrote:
>>>
 Hi Farasath,

>
> SAML Assertion size is going to depend with the number of requested
> claims, signing, encryption etc. How are we planning to handle this
> ​?
>

 ​That is a valid question! The initial value, 4096 was used in the
 IDN_SAML2_ASSERTION_STORE table. But with my implementation, later I found
 out that it's not enough and used 5120 for now. ​Is there a maximum size
 that we can decide on?

> ​
>
>

>>>
>>> --
>>>

Re: [Architecture] SAML Artifact Binding - Server Side Implementations

[Vihanga Liyanage]

Hi all,

I have completed basic flow with SAML2 artifact binding and sent a PR [1]
.
Now we have the following points to decide on.

   1. Issued SAML2 artifacts should have a shortest practical time limit
   which an artifact receiver can resolve it. We can define a property in
   identity.xml but need to define a default value for it.
   2. Currently, I have defined the endpoint to resolve artifacts as "/
   *samlartresolve*". We should decide on a suitable name if this one isn't.

Please let me know your thoughts.

Thanks,
Vihanga.

[1] - https://github.com/wso2-extensions/identity-inbound-auth-saml/pull/188

On Tue, Jul 10, 2018 at 6:14 PM Vihanga Liyanage  wrote:

> Hi all,
>
> With the discussion we had today, we have decided to go with below
> database structure.
>
> IDN_SAML2_ARTIFACT_STORE
> PK ID INT NOT NULL
>
> SOURCE_ID BLOB NOT NULL
>
> MESSAGE_HANDLER BLOB NOT NULL
>
> AUTHN_REQ_DTO BLOB NOT NULL
>
> SESSION_ID VARCHAR(255) NOT NULL
>
> INTI_TIMESTAMP DATETIME NOT NULL
>
> EXP_TIMESTAMP DATETIME NOT NULL
>
> We'll build the SAML assertion as well as the response object at artifact
> resolution time. Please let me know your concerns on this.
>
> Best regards,
> Vihanga.
>
> On Thu, Jul 5, 2018 at 8:12 AM Malithi Edirisinghe 
> wrote:
>
>>
>>
>> On Wed, Jul 4, 2018 at 9:13 PM, Vihanga Liyanage 
>> wrote:
>>
>>> Hi all,
>>>
>>> In the discussion we had today, a concern was raised about storing SAML
>>> assertions in the database as it can become quite large. The alternatives
>>> proposed are as follows.
>>>
>>>1. Store any information we need to build the SAML assertion at
>>>artifact resolution time and build it there.
>>>
>>>
>>>- AFAIU, we need following data to be stored in the database to go
>>>   with this approach.
>>>  - Attributes in SAMLSSOAuthnReqDTO object.
>>>
>>>
>>>- AuthenticatedUser
>>>- NameIDFormat
>>>- assertionConsumerURL
>>>- idPInitSSOEnabled
>>>- AuthnReq ID
>>>- requestedRecipients list
>>>- IdpAuthenticationContextProperties
>>>- Issuer
>>>- RequestedAttributes list
>>>- IssuerWithDomain
>>>- RequestedAudiences list
>>>- SigningAlgorithmUri
>>>- DigestAlgorithmUri
>>>
>>>
>>>- Timestamp
>>>  - Session ID
>>>
>>>
>>>1. Build the assertion without signature data, which will reduce the
>>>size. We can add the signature information at artifact resolution.
>>>
>>>
>>>- For this approach, we need following data to be stored in the
>>>   database apart from the built assertion.
>>>  - Attributes in SAMLSSOAuthnReqDTO object.
>>>
>>>
>>>- SigningAlgorithmUri
>>>- DigestAlgorithmUri
>>>- AuthenticatedUser
>>>
>>> Basically, algorithms can be identified by the SP.
>> When the artifact resolving request comes if we can resolve the SP we
>> could pick up the algorithms. I don't see a necessity of the authenticated
>> user here, but the tenant domain.
>> So we should be able to resolve the tenant domain from the artifact.
>>
>>
>>> Currently, I have implemented to store and retrieve complete SAML
>>> assertion as we decided earlier. AFAIU, option two would be better since
>>> option one requires complex data to be stored in the DB. Please let me know
>>> your thoughts on this.
>>>
>>
>> As Ruwan had mentioned you will have to think of the significance of each
>> property/param that you mentioned above to decide on the model.
>>
>> As I see we don't need to store all you mentioned above under (1) and
>> build the assertion later. But I see authenticated subject, authentication
>> request id as some significant attributes on any requirements to query the
>> assertion. Moreover, at the time the artifact response goes to SP, the user
>> is authenticated and the SAML assertion is the identity of that user. So I
>> don't see there would be anything that will impact on the generated
>> assertion when resolving the artifact and in returning the assertion.
>> Thus, I would opt for option 2.
>>
>> Better if you can have a look at the Assertion query profile as well. We
>> should be persisting the SAML assertion there as well or some structure to
>> query the assertion.
>> May be that implementation can be reused.
>>
>> @Omindu ,
>> May be you can give more insight on query profile and see if we can
>> relate with it's implementation in this context.
>>
>>
>>
>>> Also, do note following.
>>>
>>>- I couldn't find anything in the specifications that suggest or
>>>oppose doing any of these. (Please correct me if I'm wrong) Therefore, we
>>>have the freedom do what we see as best.
>>>- We don't execute search functions in the DB using assertions.
>>>
>>> Best Regards,
>>> Vihanga.
>>>
>>> On Tue, Jul 3, 2018 at 1:48 PM Maduranga Siriwardena 
>>> wrote:
>>>
 Databases can handle large text fields. Column type depends on the
 database. For example [1] shows few MySql column types th

Re: [Architecture] SAML Artifact Binding - Server Side Implementations

[Vihanga Liyanage]

Hi all,

We had a conflict in the last review with the SAML assertion query profile
[1] 
implementation.
*What should happen when an artifact is issued to an SP and it's not yet
resolved? Should the app be able to query the assertion according to
assertion query profile?*
I couldn't find anything in the two specifications that relate to this
situation. I've tried to see how Forgerock implementation works, but that
failed as well. Since we're on a tight schedule, I'm going with below
solution.

When artifact binding is enabled, I will check for query profile enablement
as well after building the artifact. If yes, then I'll call the
*ExtendedDefaultAssertionBuilder.buildAssertion()
[2]

*method, which will build and save the assertion in the
IDN_SAML2_ASSERTION_STORE table. I'll save the ID of this built SAML
assertion in a new column of the IDN_SAML2_ARTIFACT_STORE table.
When resolving the issued artifact, current implementation builds the
assertion using the data stored in the IDN_SAML2_ARTIFACT_STORE table.
Instead, if query profile is enabled, I'll get the assertion from the
IDN_SAML2_ASSERTION_STORE using the SAML ID.

Please do let me know your concerns.

Thanks,
Vihanga.

[1] - https://docs.wso2.com/display/IS530/Querying+SAML+Assertions
[2] -
https://github.com/wso2-extensions/identity-inbound-auth-saml/blob/d470e52885e75e10352670f53670945c2a793947/components/org.wso2.carbon.identity.sso.saml/src/main/java/org/wso2/carbon/identity/sso/saml/builders/assertion/ExtendedDefaultAssertionBuilder.java#L70

On Thu, Jul 12, 2018 at 10:40 AM Vihanga Liyanage  wrote:

> Hi all,
>
> I have completed basic flow with SAML2 artifact binding and sent a PR [1]
> .
> Now we have the following points to decide on.
>
>1. Issued SAML2 artifacts should have a shortest practical time limit
>which an artifact receiver can resolve it. We can define a property in
>identity.xml but need to define a default value for it.
>2. Currently, I have defined the endpoint to resolve artifacts as "/
>*samlartresolve*". We should decide on a suitable name if this one
>isn't.
>
> Please let me know your thoughts.
>
> Thanks,
> Vihanga.
>
> [1] -
> https://github.com/wso2-extensions/identity-inbound-auth-saml/pull/188
>
> On Tue, Jul 10, 2018 at 6:14 PM Vihanga Liyanage  wrote:
>
>> Hi all,
>>
>> With the discussion we had today, we have decided to go with below
>> database structure.
>>
>> IDN_SAML2_ARTIFACT_STORE
>> PK ID INT NOT NULL
>>
>> SOURCE_ID BLOB NOT NULL
>>
>> MESSAGE_HANDLER BLOB NOT NULL
>>
>> AUTHN_REQ_DTO BLOB NOT NULL
>>
>> SESSION_ID VARCHAR(255) NOT NULL
>>
>> INTI_TIMESTAMP DATETIME NOT NULL
>>
>> EXP_TIMESTAMP DATETIME NOT NULL
>>
>> We'll build the SAML assertion as well as the response object at artifact
>> resolution time. Please let me know your concerns on this.
>>
>> Best regards,
>> Vihanga.
>>
>> On Thu, Jul 5, 2018 at 8:12 AM Malithi Edirisinghe 
>> wrote:
>>
>>>
>>>
>>> On Wed, Jul 4, 2018 at 9:13 PM, Vihanga Liyanage 
>>> wrote:
>>>
 Hi all,

 In the discussion we had today, a concern was raised about storing SAML
 assertions in the database as it can become quite large. The alternatives
 proposed are as follows.

1. Store any information we need to build the SAML assertion at
artifact resolution time and build it there.


- AFAIU, we need following data to be stored in the database to go
   with this approach.
  - Attributes in SAMLSSOAuthnReqDTO object.


- AuthenticatedUser
- NameIDFormat
- assertionConsumerURL
- idPInitSSOEnabled
- AuthnReq ID
- requestedRecipients list
- IdpAuthenticationContextProperties
- Issuer
- RequestedAttributes list
- IssuerWithDomain
- RequestedAudiences list
- SigningAlgorithmUri
- DigestAlgorithmUri


- Timestamp
  - Session ID


1. Build the assertion without signature data, which will reduce
the size. We can add the signature information at artifact resolution.


- For this approach, we need following data to be stored in the
   database apart from the built assertion.
  - Attributes in SAMLSSOAuthnReqDTO object.


- SigningAlgorithmUri
- DigestAlgorithmUri
- AuthenticatedUser

 Basically, algorithms can be identified by the SP.
>>> When the artifact resolving request comes if we can resolve the SP we
>>> could pick up the algorithms. I don't see a nec

Re: [Architecture] SAML Artifact Binding - Server Side Implementations

[Vihanga Liyanage]

Hi all,

I have completed the implementations of the feature and now in the process
of writing an integration test suit. While doing that I faced a few issues.

The plan is to use the new IS samples in here [1]
,
since we no longer encouraged to use the Travelocity app. But this new
sample app seems to have issues when running on Tomcat 7 and I think this
is the cause for the issues I'm having with tests. Is it possible to
upgrade the Tomcat version from 7 to 8? If so what would be the procedure?

Your valuable ideas are highly appreciated.

Regards,
Vihanga.

[1] -
https://github.com/wso2/samples-is/tree/master/saml2-sso-sample/components/SAML2/saml2-web-app-dispatch

On Mon, Jul 16, 2018 at 6:24 PM Vihanga Liyanage  wrote:

> Hi all,
>
> We had a conflict in the last review with the SAML assertion query profile
> [1] 
> implementation.
> *What should happen when an artifact is issued to an SP and it's not yet
> resolved? Should the app be able to query the assertion according to
> assertion query profile?*
> I couldn't find anything in the two specifications that relate to this
> situation. I've tried to see how Forgerock implementation works, but that
> failed as well. Since we're on a tight schedule, I'm going with below
> solution.
>
> When artifact binding is enabled, I will check for query profile
> enablement as well after building the artifact. If yes, then I'll call the 
> *ExtendedDefaultAssertionBuilder.buildAssertion()
> [2]
> 
> *method, which will build and save the assertion in the
> IDN_SAML2_ASSERTION_STORE table. I'll save the ID of this built SAML
> assertion in a new column of the IDN_SAML2_ARTIFACT_STORE table.
> When resolving the issued artifact, current implementation builds the
> assertion using the data stored in the IDN_SAML2_ARTIFACT_STORE table.
> Instead, if query profile is enabled, I'll get the assertion from the
> IDN_SAML2_ASSERTION_STORE using the SAML ID.
>
> Please do let me know your concerns.
>
> Thanks,
> Vihanga.
>
> [1] - https://docs.wso2.com/display/IS530/Querying+SAML+Assertions
> [2] -
> https://github.com/wso2-extensions/identity-inbound-auth-saml/blob/d470e52885e75e10352670f53670945c2a793947/components/org.wso2.carbon.identity.sso.saml/src/main/java/org/wso2/carbon/identity/sso/saml/builders/assertion/ExtendedDefaultAssertionBuilder.java#L70
>
> On Thu, Jul 12, 2018 at 10:40 AM Vihanga Liyanage 
> wrote:
>
>> Hi all,
>>
>> I have completed basic flow with SAML2 artifact binding and sent a PR [1]
>> .
>> Now we have the following points to decide on.
>>
>>1. Issued SAML2 artifacts should have a shortest practical time limit
>>which an artifact receiver can resolve it. We can define a property in
>>identity.xml but need to define a default value for it.
>>2. Currently, I have defined the endpoint to resolve artifacts as "/
>>*samlartresolve*". We should decide on a suitable name if this one
>>isn't.
>>
>> Please let me know your thoughts.
>>
>> Thanks,
>> Vihanga.
>>
>> [1] -
>> https://github.com/wso2-extensions/identity-inbound-auth-saml/pull/188
>>
>> On Tue, Jul 10, 2018 at 6:14 PM Vihanga Liyanage 
>> wrote:
>>
>>> Hi all,
>>>
>>> With the discussion we had today, we have decided to go with below
>>> database structure.
>>>
>>> IDN_SAML2_ARTIFACT_STORE
>>> PK ID INT NOT NULL
>>>
>>> SOURCE_ID BLOB NOT NULL
>>>
>>> MESSAGE_HANDLER BLOB NOT NULL
>>>
>>> AUTHN_REQ_DTO BLOB NOT NULL
>>>
>>> SESSION_ID VARCHAR(255) NOT NULL
>>>
>>> INTI_TIMESTAMP DATETIME NOT NULL
>>>
>>> EXP_TIMESTAMP DATETIME NOT NULL
>>>
>>> We'll build the SAML assertion as well as the response object at
>>> artifact resolution time. Please let me know your concerns on this.
>>>
>>> Best regards,
>>> Vihanga.
>>>
>>> On Thu, Jul 5, 2018 at 8:12 AM Malithi Edirisinghe 
>>> wrote:
>>>


 On Wed, Jul 4, 2018 at 9:13 PM, Vihanga Liyanage 
 wrote:

> Hi all,
>
> In the discussion we had today, a concern was raised about storing
> SAML assertions in the database as it can become quite large. The
> alternatives proposed are as follows.
>
>1. Store any information we need to build the SAML assertion at
>artifact resolution time and build it there.
>
>
>- AFAIU, we need following data to be stored in the database to go
>   with this approach.
>  - Attributes in SAMLSSOAuthnReqDTO object.
>
>
>- AuthenticatedUser
>- NameIDFormat
>- assertionConsumerURL
>