axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amila Jayasekara <ami...@wso2.com>
Subject Re: establishing trust between two or more standalone STS
Date Mon, 08 Aug 2011 18:55:13 GMT
Hi Maicon,

Some answers inline.

On Mon, Aug 8, 2011 at 4:00 PM, Maicon Stihler <stihler@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 <stihler@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


Mime
View raw message