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<[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
