Trust Implementation added to trunk

[Milinda Pathirage <mi...@gmail.com>]

Hi devs,
I have added trust implementation from scratch to trunk with new features
and samples. Please feel free to try it and comment on the implementation.

Thanks
Milinda

-- 
http://think2ed.blogspot.com "thinksquared"
http://wsaxc.blogspot.com "Web Services With Axis2/C"

Re: Trust Implementation added to trunk

[Kasun Indrasiri <ka...@gmail.com>]

Hi,

>
>
> I agree with Supun. We should be able to automate the creation of
> entropy, merging the server + client entropy to create the key, etc.
> Even, if we are doing it in client, then client has to check the policy
> and then do that. So, we can easily automate it and move it to
> trust_sts_client.


Yes, I think we have to add support for the sec-policy realated things in
trust.
The next pahse of
implementation of Trust should be focussed on these things.
 I'm working on those things and I would be able come up with these
things soon.


regrads,
Kasun

Re: Trust Implementation added to trunk

[Uthaiyashankar <sh...@wso2.com>]

Supun Kamburugamuva wrote:
> Hi,
>
>   
>>> (1) sts client doesn't need service policy. Algorithm suit as well as
>>> trust assertions have to be obtained from issuer policy.
>>>       
>> I think there are few bugs related to this issue. Milinda is working on
>> those things.
>>
>> (2) if sts needs entropy from client, who is responsible for creating
>>     
>>> it?? is it trust_sts_client or implementation(client/who ever) using
>>> trust_sts_client? IMHO it should be trust_sts_client by looking at the
>>> sts policy.
>>>       
>> Entropy should be created by client (by setting trust_entropy_t in RST in
>> client code) and also STS should handle it by using populated RSTR (i.e.
>> trust_rstr_get_entropy())
>>
>>     
>
> Yes this is the responsibility of the client. But we can automate this
> by looking at the STS policy. So Kasun I think we need to implement
> this as well.
>   

I agree with Supun. We should be able to automate the creation of 
entropy, merging the server + client entropy to create the key, etc. 
Even, if we are doing it in client, then client has to check the policy 
and then do that. So, we can easily automate it and move it to 
trust_sts_client.

Regards,
Shankar
> Regards,
> Supun..
>
>   

Re: Trust Implementation added to trunk

[Supun Kamburugamuva <su...@gmail.com>]

Hi,

> > (1) sts client doesn't need service policy. Algorithm suit as well as
> > trust assertions have to be obtained from issuer policy.
>
>
> I think there are few bugs related to this issue. Milinda is working on
> those things.
>
> (2) if sts needs entropy from client, who is responsible for creating
> > it?? is it trust_sts_client or implementation(client/who ever) using
> > trust_sts_client? IMHO it should be trust_sts_client by looking at the
> > sts policy.
>
>
> Entropy should be created by client (by setting trust_entropy_t in RST in
> client code) and also STS should handle it by using populated RSTR (i.e.
> trust_rstr_get_entropy())
>

Yes this is the responsibility of the client. But we can automate this
by looking at the STS policy. So Kasun I think we need to implement
this as well.

Regards,
Supun..

Re: Trust Implementation added to trunk

[Kasun Indrasiri <ka...@gmail.com>]

Hi Shankar,

pls see my comments below.


>
>
> (1) sts client doesn't need service policy. Algorithm suit as well as
> trust assertions have to be obtained from issuer policy.


I think there are few bugs related to this issue. Milinda is working on
those things.

(2) if sts needs entropy from client, who is responsible for creating
> it?? is it trust_sts_client or implementation(client/who ever) using
> trust_sts_client? IMHO it should be trust_sts_client by looking at the
> sts policy.


Entropy should be created by client (by setting trust_entropy_t in RST in
client code) and also STS should handle it by using populated RSTR (i.e.
trust_rstr_get_entropy())

Even server challenge should be handled by trust_sts_client.


 We currently do not support 'Negotiation and Challenge Extensions' . Yeah
sts_client is responsible for handling it.

(3) when creating proof token, we can set it as binary secret or
> encrypted key. Is there any way to specify which one should be used?


There are two procedures for creating proof tokens in current trust
implementation.


1 – (Generic way)

trust_util_create_requsted_proof_token_element(
const axutil_env_t * env,
axis2_char_t *wst_ns_uri,
axiom_node_t * parent_node,
axiom_node_t *req_proof_token)

You can create any type of proof token (req_proof_token) and set it to RSTR.


2 – (Most Common procedure) We can create a random session key as the proof
token under <wst:BinarySecret> (base64encode value) , and send it to the
client. For this case we have to have the assurance that the message is
secured. (.i.e encrypted for the Client)

For that u can use
/*Generating Random Session Key*/

AXIS2_EXTERN axiom_node_t * AXIS2_CALL
trust_util_create_random_session_key_proof_token_element(
const axutil_env_t * env,
axis2_char_t *wst_ns_uri)

This is pretty much SAML 1.1 oriented, and you have to have the generated
random session key inside the SAML token as well. (sample scenario doen't do
this. )


Regards,
Kasun

Re: Trust Implementation added to trunk

[Uthaiyashankar <sh...@wso2.com>]

Milinda Pathirage wrote:
> Hi devs,
> I have added trust implementation from scratch to trunk with new features
> and samples. Please feel free to try it and comment on the implementation.
>
> Thanks
> Milinda
>
>   
Hi,

Thank you for the implementation :) . I have some comments + questions :)

(1) sts client doesn't need service policy. Algorithm suit as well as 
trust assertions have to be obtained from issuer policy.
(2) if sts needs entropy from client, who is responsible for creating 
it?? is it trust_sts_client or implementation(client/who ever) using 
trust_sts_client? IMHO it should be trust_sts_client by looking at the 
sts policy. Even server challenge should be handled by trust_sts_client.
(3) when creating proof token, we can set it as binary secret or 
encrypted key. Is there any way to specify which one should be used?

Regards,
Shankar