establishing trust between two or more standalone STS

[Maicon Stihler <st...@gmail.com>]

Hi,

I want to use apache rampart to establish a federated environment, but 
I'm having trouble to find details on how to operate the STS on a 
standalone setup.

In this scenario, I would create as many STS as there are security 
domains, and establish trust relationships between them all. Thus the 
users from each security domain could obtain security tokens to access 
services on different security domains.

Reading the documentation on the Rampart web site, it is not very clear 
how the STS is operated (e.g. how do I create a custom STS that runs 
separated from the relying party? or how do I tell the STS who should be 
trusted when validating tokens from other STSs?)

 From the samples, it seems that the STS is embedded on rampart itself, 
but I want to create an STS that acts as an attribute authority (i.e. it 
would retrieve attributes about subjects on a custom db like LDPA, 
PgSQL, etc).

I apologise for such a basic question. I've been reading about 
WS-Federation (more precisely, the active requestor profile), but I 
couldn't find any implementation for it, so I thought about of emulating 
part of it (not the metadata about the federation, autoconfiguration 
based on policies, etc) using apache rampart. I thank you in advance for 
any tips or directions to other resources on this subject.

Best regards,
Maicon Stihler

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org

Re: establishing trust between two or more standalone STS

[suresh attanayake <su...@gmail.com>]

Hi Maicon,

Federated STSs and Attribute Services are defined in the WS- Federation
Specification but currently Apache Rampart has not implemented the
Federation specification. We group of students from University of Moratuwa
are implementing this specification for Apache Rampart as a part of our
final year project and we are willing to make it available in the rampart
public svn.

thanks,
suresh..

On Sat, Aug 6, 2011 at 1:53 AM, Maicon Stihler <st...@gmail.com> wrote:

> Hi,
>
> I want to use apache rampart to establish a federated environment, but I'm
> having trouble to find details on how to operate the STS on a standalone
> setup.
>
> In this scenario, I would create as many STS as there are security domains,
> and establish trust relationships between them all. Thus the users from each
> security domain could obtain security tokens to access services on different
> security domains.
>
> Reading the documentation on the Rampart web site, it is not very clear how
> the STS is operated (e.g. how do I create a custom STS that runs separated
> from the relying party? or how do I tell the STS who should be trusted when
> validating tokens from other STSs?)
>
> From the samples, it seems that the STS is embedded on rampart itself, but
> I want to create an STS that acts as an attribute authority (i.e. it would
> retrieve attributes about subjects on a custom db like LDPA, PgSQL, etc).
>
> I apologise for such a basic question. I've been reading about
> WS-Federation (more precisely, the active requestor profile), but I couldn't
> find any implementation for it, so I thought about of emulating part of it
> (not the metadata about the federation, autoconfiguration based on policies,
> etc) using apache rampart. I thank you in advance for any tips or directions
> to other resources on this subject.
>
> Best regards,
> Maicon Stihler
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.**apache.org<ja...@axis.apache.org>
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>


-- 
Suresh Attanayake

Blog : http://sureshatt.blogspot.com/
LinkedIn : http://www.linkedin.com/pub/suresh-attanayake/16/165/181
Twitter : http://twitter.com/sureshatt

Re: establishing trust between two or more standalone STS

[Amila Jayasekara <am...@wso2.com>]

Hi Maicon,

Some answers inline.

On Mon, Aug 8, 2011 at 4:00 PM, Maicon Stihler <st...@gmail.com> wrote:
> Hi Amila,
>
> do you know if the tokens received by the service are validated against the
> STS defined on the ws-policy?

The STS and service are in a trust relationship. This is again
achievable using public key/private key mechanism. In which service
stores STS' public key. So we can say that tokens received by service
are validate against the service.

> I did some research on the rampart source code, but all I could find was a
> call to verifyTrust on the PolicyBasedResultsValidator.
>
> I was expecting something like the following:
> 1. client calls STS and asks for a token / STS issues a new token
> 2. client invokes the service with the issued token
> 3. rampart intercepts the request, and asks the STS to validate the token
> 4. if the validation status returns positive, then pass the request to the
> service, otherwise send a fault to the client

Well, i am not sure about point 3 onwards. I have to refresh my memory
about WS-Trust specification. WS-Trust spec defines several methods of
communication. One way is, client contacting STS directly, obtain
tokens and then client send message with those tokens to the service.
As far as i can remember that is why we are having
"<wst:RequestedAttachedReference>" or
"<wst:RequestedUnattachedReference>" and "<wst:RequestedProofToken>"
elements in the RequestSecurityTokenResponse element. When client gets
a token from STS, it also includes the token for end service. Client
will not be able to see the token for service since it is encrypted
using service''s public key. Therefore client will blindly copy the
key ("<wst:RequestedAttachedReference>" or
"<wst:RequestedUnattachedReference>") to request.

>
> If this is not the case, is it possible to change the rampart code to act
> this way? (I suppose this would be more in line with the WS-Trust spec)

I cant be certain about this. But i believe it should be possible as
rampart already defines necessary infrastructure for WS-Trust.

Thanks
AmilaJ

>
> Thank your help :)
>
> Em 08/08/2011 04:13, Amila Jayasekara escreveu:
>
> Hi Maicon,
>
> By default STS is embedded within rampart it self. But it is possible
> to have an external STS service and create a trust relationship with
> an another service which STS trusts. So some answers to your questions
> are as follows,
>
> how do I create a custom STS that runs separated from the relying party?
>
> For this you need to have a service which returns tokens. Thus the STS
> should also be secured using some mechanisms.
>
> how do I tell the STS who should be trusted when validating tokens from
> other STSs?
>
> This can be accomplished by using public-privatete key cryptographic
> mechanisms. For example, you can have a service secured using
> certificates. Thus this service URL and the public key certificate of
> it can be installed in a respective STS. Now whenever STS issues
> tokens for a legitimate client it will use the registered service URL
> and lookup relevant public certificate. Then STS will issue tokens by
> encrypting the token using looked up service's public key.
>
> So the communication will happen as follows,
> Client will first obtain a token from STS, then client will present
> the token to service. Service can decrypt the token since it was
> encrypted using service's public key. Since we can use SAML attributes
> i believe you can exchange relevant attribute information (Extracted
> from LDAP, DB etc ...).
>
> To implement the STS, i believe you could use
> org.apache.rahas.STSMessageReceiver. Please look at [1] for a sample
> implementation.
>
> Also with this mail i am attaching a sample client program. In the
> client program i am assuming STS is secured with user name token over
> HTTPS. You can find necessary policy files in the resources directory.
>
> One more thing, i haven't tested this with only a rampart
> distribution. I have tested this with a product which wraps rampart.
> Thus theoretically this should also work with rampart.
>
> Thanks
> AmilaJ
>
> [1]
> https://svn.wso2.org/repos/wso2/trunk/carbon/components/sts/org.wso2.carbon.sts/src/main/resources/META-INF
>
>
> On Sat, Aug 6, 2011 at 1:53 AM, Maicon Stihler <st...@gmail.com> wrote:
>
> Hi,
>
> I want to use apache rampart to establish a federated environment, but I'm
> having trouble to find details on how to operate the STS on a standalone
> setup.
>
> In this scenario, I would create as many STS as there are security domains,
> and establish trust relationships between them all. Thus the users from each
> security domain could obtain security tokens to access services on different
> security domains.
>
> Reading the documentation on the Rampart web site, it is not very clear how
> the STS is operated (e.g. how do I create a custom STS that runs separated
> from the relying party? or how do I tell the STS who should be trusted when
> validating tokens from other STSs?)
>
> From the samples, it seems that the STS is embedded on rampart itself, but I
> want to create an STS that acts as an attribute authority (i.e. it would
> retrieve attributes about subjects on a custom db like LDPA, PgSQL, etc).
>
> I apologise for such a basic question. I've been reading about WS-Federation
> (more precisely, the active requestor profile), but I couldn't find any
> implementation for it, so I thought about of emulating part of it (not the
> metadata about the federation, autoconfiguration based on policies, etc)
> using apache rampart. I thank you in advance for any tips or directions to
> other resources on this subject.
>
> Best regards,
> Maicon Stihler
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org

Re: establishing trust between two or more standalone STS

[Maicon Stihler <st...@gmail.com>]

Hi Amila,

do you know if the tokens received by the service are validated against 
the STS defined on the ws-policy?
I did some research on the rampart source code, but all I could find was 
a call to verifyTrust on the PolicyBasedResultsValidator.

I was expecting something like the following:
1. client calls STS and asks for a token / STS issues a new token
2. client invokes the service with the issued token
3. rampart intercepts the request, and asks the STS to validate the token
4. if the validation status returns positive, then pass the request to 
the service, otherwise send a fault to the client

If this is not the case, is it possible to change the rampart code to 
act this way? (I suppose this would be more in line with the WS-Trust spec)

Thank your help :)

Em 08/08/2011 04:13, Amila Jayasekara escreveu:
> Hi Maicon,
>
> By default STS is embedded within rampart it self. But it is possible
> to have an external STS service and create a trust relationship with
> an another service which STS trusts. So some answers to your questions
> are as follows,
>
>> how do I create a custom STS that runs separated from the relying party?
> For this you need to have a service which returns tokens. Thus the STS
> should also be secured using some mechanisms.
>
>> how do I tell the STS who should be trusted when validating tokens from other STSs?
> This can be accomplished by using public-privatete key cryptographic
> mechanisms. For example, you can have a service secured using
> certificates. Thus this service URL and the public key certificate of
> it can be installed in a respective STS. Now whenever STS issues
> tokens for a legitimate client it will use the registered service URL
> and lookup relevant public certificate. Then STS will issue tokens by
> encrypting the token using looked up service's public key.
>
> So the communication will happen as follows,
> Client will first obtain a token from STS, then client will present
> the token to service. Service can decrypt the token since it was
> encrypted using service's public key. Since we can use SAML attributes
> i believe you can exchange relevant attribute information (Extracted
> from LDAP, DB etc ...).
>
> To implement the STS, i believe you could use
> org.apache.rahas.STSMessageReceiver. Please look at [1] for a sample
> implementation.
>
> Also with this mail i am attaching a sample client program. In the
> client program i am assuming STS is secured with user name token over
> HTTPS. You can find necessary policy files in the resources directory.
>
> One more thing, i haven't tested this with only a rampart
> distribution. I have tested this with a product which wraps rampart.
> Thus theoretically this should also work with rampart.
>
> Thanks
> AmilaJ
>
> [1] https://svn.wso2.org/repos/wso2/trunk/carbon/components/sts/org.wso2.carbon.sts/src/main/resources/META-INF
>
>
> On Sat, Aug 6, 2011 at 1:53 AM, Maicon Stihler<st...@gmail.com>  wrote:
>> Hi,
>>
>> I want to use apache rampart to establish a federated environment, but I'm
>> having trouble to find details on how to operate the STS on a standalone
>> setup.
>>
>> In this scenario, I would create as many STS as there are security domains,
>> and establish trust relationships between them all. Thus the users from each
>> security domain could obtain security tokens to access services on different
>> security domains.
>>
>> Reading the documentation on the Rampart web site, it is not very clear how
>> the STS is operated (e.g. how do I create a custom STS that runs separated
>> from the relying party? or how do I tell the STS who should be trusted when
>> validating tokens from other STSs?)
>>
>>  From the samples, it seems that the STS is embedded on rampart itself, but I
>> want to create an STS that acts as an attribute authority (i.e. it would
>> retrieve attributes about subjects on a custom db like LDPA, PgSQL, etc).
>>
>> I apologise for such a basic question. I've been reading about WS-Federation
>> (more precisely, the active requestor profile), but I couldn't find any
>> implementation for it, so I thought about of emulating part of it (not the
>> metadata about the federation, autoconfiguration based on policies, etc)
>> using apache rampart. I thank you in advance for any tips or directions to
>> other resources on this subject.
>>
>> Best regards,
>> Maicon Stihler
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
>> For additional commands, e-mail: java-dev-help@axis.apache.org

Re: establishing trust between two or more standalone STS

[Amila Jayasekara <am...@wso2.com>]

Hi Maicon,

By default STS is embedded within rampart it self. But it is possible
to have an external STS service and create a trust relationship with
an another service which STS trusts. So some answers to your questions
are as follows,

>how do I create a custom STS that runs separated from the relying party?
For this you need to have a service which returns tokens. Thus the STS
should also be secured using some mechanisms.

>how do I tell the STS who should be trusted when validating tokens from other STSs?
This can be accomplished by using public-privatete key cryptographic
mechanisms. For example, you can have a service secured using
certificates. Thus this service URL and the public key certificate of
it can be installed in a respective STS. Now whenever STS issues
tokens for a legitimate client it will use the registered service URL
and lookup relevant public certificate. Then STS will issue tokens by
encrypting the token using looked up service's public key.

So the communication will happen as follows,
Client will first obtain a token from STS, then client will present
the token to service. Service can decrypt the token since it was
encrypted using service's public key. Since we can use SAML attributes
i believe you can exchange relevant attribute information (Extracted
from LDAP, DB etc ...).

To implement the STS, i believe you could use
org.apache.rahas.STSMessageReceiver. Please look at [1] for a sample
implementation.

Also with this mail i am attaching a sample client program. In the
client program i am assuming STS is secured with user name token over
HTTPS. You can find necessary policy files in the resources directory.

One more thing, i haven't tested this with only a rampart
distribution. I have tested this with a product which wraps rampart.
Thus theoretically this should also work with rampart.

Thanks
AmilaJ

[1] https://svn.wso2.org/repos/wso2/trunk/carbon/components/sts/org.wso2.carbon.sts/src/main/resources/META-INF


On Sat, Aug 6, 2011 at 1:53 AM, Maicon Stihler <st...@gmail.com> wrote:
> Hi,
>
> I want to use apache rampart to establish a federated environment, but I'm
> having trouble to find details on how to operate the STS on a standalone
> setup.
>
> In this scenario, I would create as many STS as there are security domains,
> and establish trust relationships between them all. Thus the users from each
> security domain could obtain security tokens to access services on different
> security domains.
>
> Reading the documentation on the Rampart web site, it is not very clear how
> the STS is operated (e.g. how do I create a custom STS that runs separated
> from the relying party? or how do I tell the STS who should be trusted when
> validating tokens from other STSs?)
>
> From the samples, it seems that the STS is embedded on rampart itself, but I
> want to create an STS that acts as an attribute authority (i.e. it would
> retrieve attributes about subjects on a custom db like LDPA, PgSQL, etc).
>
> I apologise for such a basic question. I've been reading about WS-Federation
> (more precisely, the active requestor profile), but I couldn't find any
> implementation for it, so I thought about of emulating part of it (not the
> metadata about the federation, autoconfiguration based on policies, etc)
> using apache rampart. I thank you in advance for any tips or directions to
> other resources on this subject.
>
> Best regards,
> Maicon Stihler
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
> For additional commands, e-mail: java-dev-help@axis.apache.org
>
>