In our case we can re-use *org.wso2.carbon.webapp.mgt  *for signature
validation since it has implemented it with the use of the agent code.

And we can use the agent utils (*org.wso2.carbon.identity.sso.agent) *for
unmarshelling the response

But didn't see a util to marshall the requests ? Is it missing here ?


On Fri, Aug 19, 2016 at 3:24 PM, Johann Nallathamby <[email protected]> wrote:

>
>
> On Fri, Aug 19, 2016 at 12:26 PM, Darshana Gunawardana <[email protected]>
> wrote:
>
>>
>>
>> On Fri, Aug 19, 2016 at 10:25 AM, Johann Nallathamby <[email protected]>
>> wrote:
>>
>>> This is what we have the SSO agent for.
>>>
>>
>> SSO Agent is not carbon specific. Hence it does not have reading tenant's
>> key and validating the signature.
>>
>> SSO Agent have an interface to plug carbon use cases. AS SSO valve
>> reference shared above have that specific implementation. That
>> implementation invoked via sso agent.
>>
>
> +1. That should be the way to go here also.
>
>
>>
>> Thanks
>>
>>
>>> @Rushmin, did you check the SSOAgent code? This was improved recently
>>> also and is used in AS 6.0. The goal of the implementation was to make it a
>>> library to be used everywhere in the platform. Can you please check on
>>> that? If there are any limitations we need to fix that library and try to
>>> use it everywhere we need it.
>>>
>>> Please check with Kernel team where to get this and use this.
>>>
>>> On Fri, Aug 19, 2016 at 9:56 AM, Ishara Karunarathna <[email protected]>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> On Fri, Aug 19, 2016 at 9:47 AM, Darshana Gunawardana <
>>>> [email protected]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Aug 18, 2016 at 4:43 PM, Rushmin Fernando <[email protected]>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> In current App Manager the service providers of tenants are getting
>>>>>> created in the super tenant space.
>>>>>>
>>>>>> We are in the process of creating the service providers in the
>>>>>> relevant tenants.
>>>>>>
>>>>>> In the app manager gateway, we use SAML SSO to authenticate the
>>>>>> users, and the aforementioned service providers are used.
>>>>>>
>>>>>> When it comes to validating the the SAML response signature, I can
>>>>>> see that we can re-use
>>>>>> *org.wso2.carbon.identity.sso.saml.util.SAMLSSOUtil::getX509CredentialImplForTenant()*
>>>>>>
>>>>>> As per the code, it uses the tenant key store to get the
>>>>>> certificates. And we can get the certificate by using the tenant name as
>>>>>> the alias
>>>>>>
>>>>>> @IS team, do you see any issues with re-using this code in our
>>>>>> gateway ?
>>>>>>
>>>>>
>>>>> Using this util makes gateway -which is a client side(sp) component-
>>>>> depends on the SAML component -which is server side(idp) component-
>>>>>
>>>>> IMO, its not nice to have that dependency. Once example is, this
>>>>> dependency will expose you a samlsso (idp) endpoint from the gateway. And
>>>>> also gateway profile would need to have saml components and makes you to
>>>>> have whole framework related dependencies as well.
>>>>>
>>>>> Thinking about client side (sp) components which already doing this
>>>>> there are two components we have in wso2 platform.
>>>>> 1. Carbon SAML authenticator : https://github.com/wso2-exte
>>>>> nsions/identity-carbon-auth-saml2
>>>>> 2. AS SSO valve : https://github.com/wso2/carb
>>>>> on-deployment/blob/4.7.x/components/webapp-mgt/org.wso2.carb
>>>>> on.webapp.mgt/src/main/java/org/wso2/carbon/webapp/mgt/sso/S
>>>>> AMLSignatureValidatorImpl.java
>>>>>
>>>>> Better to use utls from those two components, if we have such methods.
>>>>> Most suitable component for gateway is #2, since carbon authenticator 
>>>>> don't
>>>>> have usage in gateway.
>>>>>
>>>>> I guess it's even worthy initiate separate component to handle all
>>>>> these saml utils, given that we have isolated components across the
>>>>> platform and we have to fix huge number of components if we identified a
>>>>> core issue.
>>>>>
>>>> +1 with darshans idea. And later better to have some common set of
>>>> libraries to handle this kind of scenarios.
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>>> @Amila, in a cloud story do we need to configure the key aliases for
>>>>>> each tenant or can we live with the default alias (which is the tenant
>>>>>> domain name) ?
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Best Regards*
>>>>>>
>>>>>> *Rushmin Fernando*
>>>>>> *Technical Lead*
>>>>>>
>>>>>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware
>>>>>>
>>>>>> mobile : +94772891266
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>>
>>>>>
>>>>> *Darshana Gunawardana*Associate Technical Lead
>>>>> WSO2 Inc.; http://wso2.com
>>>>>
>>>>> *E-mail: [email protected] <[email protected]>*
>>>>> *Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Ishara Karunarathna
>>>> Associate Technical Lead
>>>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>>>
>>>> email: [email protected],   blog: isharaaruna.blogspot.com,   mobile:
>>>> +94717996791
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Thanks & Regards,
>>>
>>> *Johann Dilantha Nallathamby*
>>> Technical Lead & Product Lead of WSO2 Identity Server
>>> Governance Technologies Team
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile - *+94777776950*
>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>>>
>>
>>
>>
>> --
>> Regards,
>>
>>
>> *Darshana Gunawardana*Associate Technical Lead
>> WSO2 Inc.; http://wso2.com
>>
>> *E-mail: [email protected] <[email protected]>*
>> *Mobile: +94718566859 <%2B94718566859>*Lean . Enterprise . Middleware
>>
>
>
>
> --
> Thanks & Regards,
>
> *Johann Dilantha Nallathamby*
> Technical Lead & Product Lead of WSO2 Identity Server
> Governance Technologies Team
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - *+94777776950*
> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
>



-- 
*Best Regards*

*Rushmin Fernando*
*Technical Lead*

WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware

mobile : +94772891266
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to