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 'saml'

 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:



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:
DefaultSTSIssuedTokenConfiguration config = new DefaultSTSIssuedTokenConfiguration();
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());

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, 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.

 Building an STS with Metro

  • January 4th, 2010
  • 10:25 pm

One of my recent tasks has been to see if it was possible to implement an OIO-Trust-compliant STS using the Metro stack from Sun. Metro contains WSIT, which has a number of classes for building an STS, so it’s not that hard. However, large portions of the code is quite undocumented, so I decided to write some of my findings down, hence this post (which is probably only interesing to a very few people).

First of all, OIO-Trust is a Danish WS-Trust profile, which basically says how Issue requests should look. The basic premise is that in order to invoke a SOAP service, you need a token. The STS issues the token based on some criteria using the WS-Trust protocol on top of SOAP.
In OIO-Trust, the Issue request must be signed, and it must contain a so-called bootstrap token. The bootstrap token is a SAML 2.0 assertion. Furthermore, the request must contain the X509 certificate which is used to sign the message. The token requested in the Issue request is a PublicKey (that is, asymmetric) of type SAML 2.0. So, the input is a SAML 2.0 assertion, and the output is also a SAML 2.0 token. More specifically, the output is a holder-of-key token, which has the requestors X509 certificate in the SubjectConfirmationData. The assertion is signed by the STS, and contains by default all the attributes from the input assertion.

In order to create an STS using Metro, you need to

  • Configure the Metro servlet in web.xml
  • Implement a simple STS endpoint class
  • Create a WSDL and a security policy
  • Create a number of services for handling attributes, configuration, etc

Configuring web.xml
This assumes that you’re using a simple servlet container. If the container supports JAX-WS, it shouldn’t be necessary.
When using Metro, all requests go through the same servlet, the WSServlet. The exact endpoint implementation used is then configured in another file, WEB-INF/sun-jaxws.xml. Therefore, simply add the following to web.xml:



This maps all requests to /services to Metro.

Implement the STS endpoint
Implementing the endpoint is quite simple, as it’s simply a question of extending a Metro class and injecting a resource. Here is a basic implementation:
import javax.annotation.Resource;
import javax.xml.transform.Source;


public class TokenService extends BaseSTSImpl implements Provider{
protected WebServiceContext context;

protected MessageContext getMessageContext() {
MessageContext msgCtx = context.getMessageContext();
return msgCtx;


No changes should be necessary, as the BaseSTSImpl class will handle all WS-Trust communication. What you need to do is to configure the base class according to the local requirements. More on that a little later.

In order to wire the STS endpoint into Metro, you need to create a WEB-INF/sun-jaxws.xml file. The file should contain something like this:



This binds the TokenService implementation to the url /services/sts using SOAP 1.1 (specified by the binding attribute).

Creating the WSDL and policy file
This is by far the hardest part of creating an STS for Metro. The WSDL should be pretty standard, and the same file can be used for all implementations. However, the WSDL file must also contain a security policy, as defined by WS-SecurityPolicy, and writing the policy can be pretty complicated. Netbeans has some support for writing policies, but I prefer to do it by hand because then you’re sure what you’ll get (once you understand WS-SecurityPolicy, that is).

The WSDL file tends to get somewhat large, so I won’t include it here – instead, you can download it if you want to see it. Basically, the WSDL is split into two parts: The regular WSDL stuff with types, messages, porttypes, bindings, and services, and the WS-SecurityPolicy stuff. Normally, the policy consists of 3 parts: The service policy which defined which tokens should be used, and how the security header layout should be, a policy which defines signature and encryption requirements for the request, and a policy for the response. These parts are then wired into the normal WSDL using PolicyReference elements.
In the example file, the service policy defines that we’re using an asymmetric binding (that is, the tokens should be different in the request and response – for example when using public/private keys). The policy also says something about the layout, and that the security header must contain a timestamp. Finally, it also enabled WS-Addressing.

Because this is an STS, the WSDL also contains a third part, namely static configuration of the STS. This includes configuring which certificates to use, how to validate incoming requests, and how tokens should be created.

Basically, this finishes the configuration of a very basic STS. However, there are some aspects which probably require some adjustments.

Checking if the requesting entity is allowed to access the requested service
When a client requests a new token, it includes a reference to the service in the AppliesTo element. Sometimes, there might be restrictions on who can access what. The Metro STS can check if the client is allowed to access a service by implementing the interface. The interface has one method, isAuthorized(subject, appliesTo, tokenType, keyType), which returns true or false:
package dk.itst.oiosaml.sts;


public class AutorizationProvider implements STSAuthorizationProvider {

public boolean isAuthorized(Subject subject, String appliesTo, String tokenType, String keyType) {
return true;

Metro uses the standard JDK service mechanism to discover implementations of this interface. That means that you should create the file /META-INF/services/ under your source directory and populate the file with the fully qualified classname of the implementation – in this example, create /META-INF/services/ with the contents dk.itst.oiosaml.sts.AuthorizationProvider.

Speficying attributes
Normally, you probably want to be able to configure the contents of the generated assertion, at the very least the attributes used, as well as the NameID of the subject. This is also done using a service implementation, this time using the interface.

The STSAttributeProvider interface has one method, getClaimedAttributes(subject, appliesTo, tokenType, claims), which returns a map of all the attributes and their values.

The subject contains information about the requesting client, in our example identified by a X509 certificate. The claims object contains any claims included in the request. It also holds any tokens included in OnBehalfOf or ActAs. These tokens are placed in claims.getSupportingProperties(), where they can be read as Subject objects. Here’s an example on reading an assertion, which has been included in ActAs:
private Assertion getSubject(Claims claims) {
Subject subject = null;
for (Object prop : claims.getSupportingProperties()) {
if (prop instanceof Subject) {
subject = (Subject) prop;
if (subject != null) {
Set creds = subject.getPublicCredentials(Element.class);
if (!creds.isEmpty()) {
Element assertion = creds.iterator().next();
try {
Assertion saml = SAMLAssertionFactory.newInstance(SAMLAssertionFactory.SAML2_0).createAssertion(assertion);
return saml;
} catch (Exception e) {
return null;

The attribute provider can then be implemented – here’s an example where the attributes from the ActAs assertion are simply copied to the resulting assertion:
public Map> getClaimedAttributes(Subject subject, String appliesTo, String tokenType, Claims claims) {
Map> res = new HashMap>();
Assertion assertion = getSubject(claims);
if (assertion != null) {
AttributeStatement attrs = getAttributes(assertion);
for (Attribute attr : attrs.getAttributes()) {
List values = new ArrayList();
for (Object val : attr.getAttributes()) {
res.put(new QName(attr.getName()), values);

res.put(new QName(assertion.getSubject().getNameId().getNameQualifier(),
return res;

Notice the last statement, where the NameID is added. The Metro STS will check if an attribute with the name STSAttributeProvider.NAME_IDENTIFIER is present, and in that case use that as the NameID of the subject in the generated assertion.

Handling configuration
The Metro STS must be know all services for which it can issue tokens. These services can either be configured statically in the WSDL file, or they can be provided programmatically. The static configuration is probably only interesting when developing, in a production environment, you probably want to build a nice admin console where services can be added and removed at runtime.

Static configuration takes place in the STSConfiguration element in the WSDL file. It can contain a ServiceProviders tag, which can then contain a number of ServiceProvider tags. Each ServiceProvider must be configured with an endpoint (the AppliesTo value), a certificate, and a token type:





The static configuration also contains information about the STS’ own id (the Issuer element), as well as the lifetime of issued tokens. The CertAlias value of a ServiceProvider must point to an alias in the trust store.

Programmatic configuration
Controlling configuration programmatically is a question of providing a service implementation of This interface has a single method, getSTSConfiguration(), which returns a configuration object – either your own implementation or an instanceof DefaultSTSConfiguration.

That more or less concludes my findings for now. There are a number of details I haven’t covered here, but I’ll wait with that until another time.

 OIOSAML Workshop

  • March 30th, 2009
  • 5:30 pm

Tomorrow, we’re co-hosting a workshop on OIOSAML together with NITA. Two hands-on sessions have been planned where people can come and get their hands dirty with the Java and .NET implementations. I’ve prepared a 15GB VMWare image with everything on it, so hopefully, it will work out somewhat nicely.

However, I’m not quite sure it will. It took me close to 3 days to configure the image, and while it may say something about my skills, I believe it says more about how complex security and webservices are. I’ve been working hard on this for over a year now, and I still have problems if I stray from the quite narrow path which I know. I wouldn’t want to be someone who is thrown into this, probably with the words “you just need to download a couple of packages, and then you’re up and running).

The worst part is that once again I can feel the vicious WS-pull – I’m getting more and more involved in this stuff, but there’s no exit route. And I believe I’ve actually thought “SOAP isn’t all that bad” a couple of times – although that was in comparison with the full-fledged WS-Security/SAML 2.0/WS-Trust stack. Still… it can’t be a good sign.

On the positive side, it looks like we’ve succeeded in making OIOSAML.Java somewhat usable, also for those not deeply familiar with SAML. On top of that, we just launched last week, which actually uses OIOSAML.Java in pristine form. That’s the first time in a very long time that I’ve had a system in production.

Just in case anybody should be interested (and able to read Danish), here’s the recipe for setting up the VMWare image.

 The Horrors of Microsoft

  • December 11th, 2008
  • 6:21 pm

I don’t really like Microsoft. Nothing new there, anything MS has been out of my computer for a very long time (except from a couple of VMWare images). I’ve never done any real development on Windows, and I haven’t wanted to. I have, however, heard many people ramble about how great Visual Studio is, so up until recently, I had the feeling that maybe I was missing out on something. I now know that I was not.

The past few weeks, I’ve been working on interoperability between identity based webservices. I won’t go into any more detail than saying that it involves, among others, these specs: SAML 2.0, XML DSig, XML Encryption, WS-SecurityPolicy, WS-Trust, and Liberty ID-WSF. Plus of course basic SOAP, WS-Addressing, and WS-Security. On Java, a lot of this is handled by Metro/WSIT, but we’ve also had to write our own WS-Trust client, and a SOAP client for generating just the right requests with the right signatures.

On the Micrsoft side, there’s the absolutely fantastic and revolutionary Geneva API. Of course, by fantastic I mean completely undocumented and untested, and by revolutionary I mean a WSIT ripoff.

That just about sets the mood. We were asked to do a simple setup which could demonstrate interop between a Java client and a .NET service. Should be easy. Microsoft people told us at a meeting that everything was supported, so there should be no problems. Except there were. And are. Two weeks later, we’ve not made much progress – it’s still not possible to send a signed request and get a signed response back, and WCF/Geneva just keeps on throwing exceptions in weird places.

Based on this quite unpleasant time, here are some of my main issues:

  • Who in his right mind would want exception messages localized? Localized exceptions are often completely meaningless, and quite obviously translated by Babelfish anno 1998. At the very least include an error code, but no. Or even better, make it possible to switch language. Also no.
  • When returning a SOAP fault, why not include the original error message? InvalidSecurity can mean anything, but if the service exception says “unable to find element with id #xxx referenced from signature xxx”, why not send that out? Or at least log it somewhere?
  • Overselling. Geneva is advocated as something which will rock your world and solve all problems. Except it won’t, and many scenarios have never been tested. Or if they have, information about it is not available anywhere.
  • Source code. I can live with poor documentation, but then at least make it possible for me to go look at the source when there’s something which doesn’t work as expected. It might not be pretty (I’ve spent a good amount of time in the WSIT source, and that’s not necessarily pleasant, but it gets the job done. I can even patch it. Who would have thought it possible???), but you’re never completely stuck. With most Microsoft products, once you’ve found out that something doesn’t work as you expected, you can try googling, ask on a forum, and that’s just about it.
  • Visual Studio. Who actually think that this is a pleasant environment? The very least they could to is to buy ReSharper, but where’s Quick Fix? Where’s type completion which is actually useful? Why does the object browser suck so badly? Where has all the LOCs gone for Visual Studio?
  • Debug logging. Look at just about any Java API, and there’s lots of debug logging just waiting to be enabled. Number of debug lines in Geneva encountered so far: 0. Thanks for the help.

There are probably somebody out there who think I’ve missed the point completely, and that I’m completely ignorant. I won’t say that it’s completely unthinkable, but when I’m done with this project, I’ll not be going near anything Microsoft for a very long while. in public release

  • July 24th, 2008
  • 4:07 pm

Vacation is over, and we’ve finally come to the point where we have published to the general public. It’s probably not of great interest to that many, but if you are one of the lucky people who have to implement a SAML 2.0 Service Provider in Java, this might be something for you.
As the name suggests, the implementation is done primarily with OIOSAML in mind, but it should be usable with just about any identity provider – we have tested with PingFederate and SimpleSAMLphp.
The downloadable files include source, demo war file, and documentation, and we’ve tried to make it as easy as possible to install. is licensed under MPL 1.1, so it should be usable in most circumstances.

 REST, Architecture, Privacy

  • June 25th, 2008
  • 5:51 pm

As you probably know, I’m involved in the OIOREST work for NITA. The work is progressing slowly, but recently I’ve had some thoughts on REST which I thought were sharable.

First of all, REST invites to a completely new kind of architecture. Nothing new here, it’s been known as mashups for a while, but I don’t think the relevance of this has been very obvious. Mashups are often taken to be something non-enterprisey about combining data in new ways, preferably in the browser by using some sort of Javascript. One thing is the possibility of combining data in new ways, but equally interesting is the fact that a lot of data manipulation is moved from a central service to distributed clients. In the good old WS-* world, mashups are known as ESBs. An enterprise service bus, whatever that is, is orchestrated into making web service calls to different services, transforming the results, combining them, and returning a complete document to the caller. The net effect is more or less the same: You get a page with the data you wanted to see (hopefully), but the ways it’s done are just about as different as they can get.
I’ve been on quite a number of projects where one service had to call another service in order to return a complete result. This gives long chains of service calls, and lead to highly coupled systems which are not very fault tolerant. With REST, it’s suddenly much easier to just return a document with references to other documents, and if it’s necessary, the client can fetch the other documents, and in the process utilize HTTP caching and other well-known mechanisms. This way, a client can fetch a root document, and immediately show the page and then fetch the rest of the data – what Martin Fowler calls Segmentation By Freshness.
Unfortunately, I’ve not seen any “enterprise systems” use REST like this, but I can’t see why it should not be possible, and even better than the WS-approach.

The second point about REST is about privacy. This is a hot topic in Denmark at the moment – a new national digital signature is on the way, and we’re helping NITA implement Single Signon using SAML 2.0. SSO makes it easier to acccess protected resources, but it also makes it harder to maintain privacy as a citizen. Most people look at SSO and the government pragmatically and trust that the government will do no harm. I guess I belong to that group to some degree, but other people, like Stephan Engberg maintains that the government should not be trusted, and that data should forever be owned by the person behind it, and nobody but the person should be able to combine it with data from other systems. Typically, this is accomplished by using pseudonyms – the person essentially gets a new identity for each system, and nobody knows all the identities (unless the person revals some or all of them).
I quit agree with this, I just can’t see how it can be implemented just now. However, REST looks like a good technology to use here. REST is relevant because, as mentioned above, it moves the responsibility for combining data from a closed system to an open client. With REST, a client can retrieve data from different sources, using different identities, and combine it locally, and the person behind the computer will be the only one to ever know. The same principles apply when
Of course there are details like XSS, trusting the client code not to do something wrong, and so on, but again: it’s all based on an open platform, and if you’re worried, you can make your own client.

I doubt anything like this will happen anytime soon – the tax office probably won’t like not being able to combine data automatically to prevent fraud, so we’ll probably just work on REST services which are not people related for now.

 Testing legacy code

  • April 10th, 2008
  • 9:06 pm

I’m currently working on an open source SAML 2 toolkit for the National IT and Telecom Agency. Exciting stuff in many ways, but mostly because we might contribute to the adoption of SAML in a pretty constructive way. I still think that SAML is overly complicated at times, and the closed nature doesn’t make it very scalable – every service provider has to be registered in the identity provider up front in order for anything to work, which is a huge maintenance issue. However, with the right setup, it doesn’t have to be that complicated. We’re developing a servlet filter, which can be plugged into any Java-based web-application in order to protect it with SAML single signon. The work is based on code developed elsewhere, and when we received it, there were no unit tests. At all.
No tests is not exactly the best way to start off, so the first tasks on our backlog was to implement unit tests for as much as possible. While the code is not exactly legacy, it’s still written by someone else, and structured in a way that you don’t quite understand.
Writing unit tests under these circumstances neither easy nor fun. There are clear advantages, though: the code will be tested, and any further work can proceed with a much higher level of confidence, and the code will be refactored intensively in the process. The refactorings happen for two reasons: to better understand the code, and to make the code testable.

So far, the main obstacles for testing have been

  • Passing around too “large” objects – for instance a HttpServletRequest only a single request parameter is needed
  • Calling static methods
  • Relying on static initializers to configure a class, for example from a file on the file system
  • Using singletons and calling them everywhere
  • Methods with side effects – why should a method named getId() put something in the HttpSession?

All of this can be refactored to make it testable. One can only wonder why it wasn’t written that way from the beginning. Anyways, the tests have been written, and the quality of the code base has increased considerably. Because of the tradition of always including new technologies in projects, this has also been the first time I’ve used JUnit 4 and jMock 2 extensively, and I quite like both of them. Especially jMock has helped a lot, and it has a very nice API.

For those who are interested, the SAML toolkit is based on OpenSAML 2, and will be released under an open source license (I’m guessing MPL) at Softwarebørsen at some time in the near future. It’s main focus is on supporting OIO-SAML, but it should support just about any SAML 2 compliant setup.