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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
>> 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: [email protected]
>> Mobile: +94718990591
>> Blog: *https://madurangasiriwardena.wordpress.com/
>> <https://madurangasiriwardena.wordpress.com/>*
>> <http://wso2.com/signature>
>>
>
>
> --
>
> Vihanga Liyanage
>
> Software Engineer | WS*O₂* Inc.
>
> M : +*94710124103* | http://wso2.com
>
> [image: http://wso2.com/signature] <http://wso2.com/signature>
>


-- 

*Ruwan Abeykoon*
*Associate Director/Architect**,*
*WSO2, Inc. http://wso2.com <https://wso2.com/signature> *
*lean.enterprise.middleware.*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to