Skip to Content »

online discount medstore
advair diskus for sale
buy advair diskus without prescription
allegra for sale
buy allegra without prescription
aristocort for sale
buy aristocort without prescription
astelin for sale
buy astelin without prescription
atarax for sale
buy atarax without prescription
benadryl for sale
buy benadryl without prescription
buy clarinex without prescription
clarinex for sale
buy claritin without prescription
claritin for sale
buy flonase without prescription
flonase for sale
buy ventolin without prescription
ventolin for sale
amoxil for sale
buy amoxil without prescription
augmentin for sale
buy augmentin without prescription
bactrim for sale
buy bactrim without prescription
biaxin for sale
buy biaxin without prescription
buy cipro without prescription
cipro for sale
buy cleocin without prescription
cleocin for sale
buy dexone without prescription
dexone for sale
buy flagyl without prescription
flagyl for sale
buy levaquin without prescription
levaquin for sale
buy omnicef without prescription
omnicef for sale
amaryl for sale
buy amaryl without prescription
buy cozaar without prescription
cozaar for sale
buy diabecon without prescription
diabecon for sale
buy glucophage without prescription
glucophage for sale
buy glucotrol without prescription
glucotrol for sale
buy glucovance without prescription
glucovance for sale
buy micronase without prescription
micronase for sale
buy prandin without prescription
prandin for sale
buy precose without prescription
precose for sale
buy cialis professional without prescription
cialis professional for sale
buy cialis soft without prescription
cialis soft for sale
buy cialis super active without prescription
cialis super active for sale
buy cialis without prescription
cialis for sale
buy levitra without prescription
levitra for sale
buy viagra professional without prescription
viagra professional for sale
buy viagra soft without prescription
viagra soft for sale
buy viagra super active without prescription
viagra super active for sale
buy viagra super force without prescription
viagra super force for sale
buy viagra without prescription
viagra for sale
buy celebrex without prescription
celebrex for sale
buy colcrys without prescription
colcrys for sale
buy feldene without prescription
feldene for sale
buy imitrex without prescription
imitrex for sale
buy inderal without prescription
inderal for sale
buy indocin without prescription
indocin for sale
buy naprosyn without prescription
naprosyn for sale
buy pletal without prescription
pletal for sale
buy robaxin without prescription
robaxin for sale
buy voltaren without prescription
voltaren for sale

Tech Life of Recht » archive for 'web services'

 Using ActAs with Metro

  • January 5th, 2010
  • 12:18 pm

Yesterday, I wrote about how to implement an STS with Metro. The reason for implementing an STS in the first place is that it enables identity delegation, something you probably want if you need to access a service on behalf of a specific user. The general flow is that the user authenticates, probably using SSO of some kind, and access a website. The site invokes a service on behalf of the user, and the service needs to be pretty sure that the user is actually sitting in the other end, even though there is no direct communication between the user and the service. The job of the STS is to be the one, everybody trusts, so that when the STS issues a token which says that the user is valid, then the service can trust that this is actually the case.

All of this can be done more or less automatically with Metro (at least when using a nightly build) by using this service policy:
[code]





urn:localsts

http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0
http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey






















[/code]

Here, we express that the service requires an issued token of type SAML 2.0. Issued token means that the token has been created by an STS. In this case, we specify that the STS identified by urn:localsts must issue a token of type SAML 2.0. The exact location of the STS needs to be configured in the client.

Unfortunately, WS-SecurityPolicy does not make it possible to express the requirements for the WS-Trust Issue request. When using identity delegation, two sets of credentials should be passed to the STS: The client credentials, for example an X509Token or a UsernameToken, and the user credentials. The client credentials are provided using standard WS-Security mechanisms, and the user credentials are included in the Issue request using the ActAs element.

As shown in the STS example, the STS policy file takes care of the client credentials by specifying the appropriate tokens. The user credentials token cannot, however, be expressed in the policy, so it needs to be agreed upon out of band. This also means that you have to provide it manually to the client.

Luckily, it’s pretty easy to add an ActAs token to the client. Normally, the client is generated using wsimport. In this example, the service is called ProviderService:
[code]
DefaultSTSIssuedTokenConfiguration config = new DefaultSTSIssuedTokenConfiguration();
config.setSTSInfo(“http://docs.oasis-open.org/ws-sx/ws-trust/200512”,
“http://localhost:8080/sts/sts”,
“http://localhost:8080/sts/sts?wsdl”,
“SecurityTokenService”,
“ISecurityTokenService_Port”,
“http://tempuri.org/”);
config.getOtherOptions().put(STSIssuedTokenConfiguration.ACT_AS, createToken());

STSIssuedTokenFeature feature = new STSIssuedTokenFeature(config);
ProviderService service = new ProviderService();
Provider port = service.getProviderPort(feature);
EchoResponse result = port.echo(new Echo());
[/code]

Here, we create a new configuration object, set the endpoint information for the STS, and add an ActAs token. The contents of the ACT_AS attribute should be an instance of com.sun.xml.ws.security.Token, for example a com.sun.xml.wss.saml.Assertion. Normally, you don’t generate the token yourself. Instead, you get it as part of the initial authentication response – for example, if you’re using SAML 2.0 web SSO, one of the attributes received might be the ActAs token that should be passed to the STS when invoking services.

 REST vs WS-*

  • April 22nd, 2008
  • 8:10 pm

Today, we had the OIOREST workshop, a workshop on the OIOREST initiative, we’re a part of at Trifork. The workshop was meant to inform about REST in the Danish public sector and to hear what users and developers had to say. The workshop went pretty well – not a lot was changed, but at least we were (more or less) confirmed in our view that REST does have its place.
The workshop was centered around a couple of Open Space sessions. One of the topics discussed was “REST vs WS-*”. While working with OIOREST, this topic has come up again and again: What is REST in relation to SOAP and WS-*, and when should each be used? This has been the basis for many heated discussions, and today was not much different. Most people say something like “REST is for simple things, but when things get too complicated, you’ll want to use WS-*”. I can’t really figure out what to think about this. First of all, what is simple and what is complicated? Complicated scenarios often include transactions and reliability. Distributed transactions are evil, period. Reliability is handled in REST by adhering to the HTTP verbs and keeping operations idempotent, so that’s not really a good argument either. Another argument against REST is “now we’ve finally developed all these standards for SOAP, why should we then do the same for REST?”. Ignoring that REST is older than SOAP and WS-*, somehow this argument also feels wrong.

I agree that REST is not for everything: if you want a RPC interface, don’t use REST. If you work in an organization which is committed to SOAP-based web services, don’t use REST (at least not openly). If you have the need for hierarchical data in the message header, REST doesn’t quite fit. If you want to use only GET/PUT/DELETE/POST, it will for example, be hard to implement transfers between two accounts in REST.
Now, everything is possible, and all of this can be modeled in REST, but it’s starting to look wrong and diverge from “real” REST. Something like WS-Security seems hard to implement in a nice way in REST. WS-Security makes it possible to sign and/or encrypt XML payloads transparently. The signature is placed in the SOAP header, and the payload format does not have to support digital signatures directly. If you need end-to-end security, this is a pretty nice thing, and REST does not have something similar. Some payload formats, for example Atom Publishing Protocol, supports signatures as a part of the payload itself. WS-Security still has the advantage that no matter what format you’re using, you can use the same mechanism for signing and checking signatures.

WS-Security has some potential, but I’ve also seen a lot of cases where WS-Security could be replaced by plain SSL instead together with a simple Authorization header. So, the original question is still valid: what are the scenarios where SOAP/WS-* simply cannot be avoided? My guess is that there is no good answer for this, just as there is no good answer to the question “when should we use Ruby instead of Java?”, or “when should we use PostgreSQL instead of MySQL?”. The answers to these questions will depend on who you are, what your experience is, where you’re working, and so on. The only way is probably to try some different scenarios in REST and SOAP and see what approach is most successful – which is what we’re in the process of doing with the Danish Nature and Environment Portal, but more about that another day.

 REST in the Danish public sector

  • March 25th, 2008
  • 10:04 pm

At Trifork, we have had a number of different consulting jobs in the Danish public sector, especially for the National IT and Telecom Agency (who is also sponsoring development of OpenUDDI). Among other things, we’ve been deeply involved in OIOWSDL, a WSDL profile for the Danish government. This profile specifies how to use WSDL and XML Schemas to do contract-first development. All in all quite reasonable – you can always argue whether the correct choices have been made, but at least you don’t have to make them yourself.
I had the somewhat doubtful honor of ensuring that OIOWSDL is compatible with all the popular platforms out there – which means that I’ve tested OIOWSDL-conforming WSDL and XSD with IBM RAD, BEA WebLogic, .NET 2 and 3, Ruby, Axis 1 and 2, and others. I already knew that web services were complicated, but that exercise really made the complexity clear. As an added bonus, I’ve been haunted by web services ever since because I’m now the guy who knows everything about them. This is also why the term WS-Deathstar is not accurate – it should be WS-Blackhole, because once you’ve come too close, you’ll never get away.

So, it was quite a change when we were asked to help with a REST profile (OIOREST). For me, it made perfect sense – REST provides much easier access to data, and interoperability is also much easier to accomplish. Unfortunately, it’s only in Danish, but we’ve taken the first steps and written a draft of the profile. The draft can be downloaded at oiorest.dk where you can also find an invitation to a workshop. The workshop is open for everybody who is interested, and the purpose is to extract experiences and attitudes towards REST.
oiorest.dk also sports two examples of what types of REST services we see. Feel free to play with them, but don’t use them for production.

It will be interesting to see where OIOREST will go from here. My hope is that more data will become public accessible – for example the Central Business Register, polution information, and all the other stuff that’s hidden away right now.