2000s XML mania continues to hold modern software back. But there are lasting lessons we can still learn from it.

XML Signatures are a bad idea executed even worse


# Why SCIM exists

Imagine you’re running a relatively large company, one with a few thousand employees. All of those employees use at least some software to do their jobs. It’s probably safe to assume that you’re dealing with hundreds of different SaaS applications across the company. You’ll have an app for approving expenses, an app for managing salespeople’s compensation, an app for piping data into your data warehouse, and much more. There’s an awfully long list of stuff.

Every employee needs access to some subset of apps. They need to do their jobs, after all. But you can’t give everyone access to everything. That’d cause all kinds of security, compliance, and practical problems. You need a way to assign different permissions to different people. 

To handle access and permissions all in one centralized place, companies tend to use IT management software like Entra, Okta, or OneLogin (among many others); people tend to describe these tools as identity providers. 

An identity provider (IDP) behaves a bit like a database. It maintains a list of employees along with a bunch of information about each person. Similarly, it maintains a list of different software applications. It keeps track of the mappings between people and applications. It’s very easy for the IT team to modify and create relationships between records.

Simply having a list of users and their access privileges in a database doesn’t help anyone much, though. The identity provider also needs to communicate information about users with other software. 

The identity provider basically needs to communicate three kinds of changes to other software:
1. The addition of new users (e.g. new hires)
2. The change of any existing user’s attributes (e.g. name, job title, etc.)
3. The removal of any existing users (e.g. departing employees)

Identity providers typically rely on a standard called SCIM (the System for Cross-domain Identity Management) for these three communication tasks. They use SCIM to make every integration with other software look roughly the same, which eliminates the need for complicated bespoke integrations with the myriad applications they need to support.

# What SCIM (basically) does
At a certain level of abstraction, a SCIM implementation looks a bit like a CS101 problem set. All we’re doing is making one list in your software look like another list in your customer’s software. 

Put very simply, SCIM just defines some rules for the JSON that the identity provider sends and the JSON that the identity provider expects to receive in response. The JSON we’re trading with the identity provider exists solely to help us perform matching CRUD operations.

Let’s go through a conceptual example.

Suppose you’re selling a new inventory management system to Dunder Mifflin. Their IT team wants you to provision users programmatically from their identity provider. They have a list of users that need access to the inventory software:
- Kevin Malone, Accountant
- Darryl Philbin, Shipping Manager
- Creed Bratton, Quality Assurance Representative

Great – via SCIM, you’ll get a pretty standardized block of JSON telling you which users to create. With that block of JSON, you’ll modify your Users table to include records for Kevin, Darryl, and Creed.

Suppose Darryl gets transitioned to a new role as Marketing Director. Great, IT updates his title in the identity provider. Within a few moments, you’ll get a standard block of JSON telling you to change Darryl’s job title. You’ll again just modify your Users table. Nothing too crazy.

Given Darryl’s job change, the Dunder Mifflin IT team decides he doesn’t need access to his account in the inventory management system anymore. Great, they just remove the mapping between Darryl and your software in their identity provider. Before long, you receive a standard block of JSON that tells you to deprovision – remove – Darryl’s account. You’ll make the corresponding changes in your Users table.

That’s all that SCIM is trying to do.

# What SCIM isn’t
We often meet people who think SCIM support means that they need to make major changes to their software. This really should not be the case. Here, I’ll go through a few common misconceptions. 

SCIM doesn’t really have anything to do with compliance. SCIM isn’t really related to SOC 2, even though there’s probably overlap in the kinds of customers who care about SCIM and the customers who care about SOC 2.

SCIM doesn’t really have anything to do with data retention. This is usually a separate conversation you might need to have with your customer.

SCIM doesn’t have any direct effect on your single sign-on implementation. Although it’s typical for people to use SCIM in combination with SAML SSO, these two standards actually don’t need to exist together or interact at all. It would be unusual, but you could use SCIM to manage users that use vanilla passwords to access your software. 

SCIM doesn’t have any direct effect on how you manage your sessions. You can use whatever session management tools you’d like. Relatedly, SCIM doesn’t require single log-out support. If you receive an instruction from your customer to deprovision a user, you don’t typically need to revoke any active sessions belonging to that user. 

SCIM doesn’t require major changes to your users schema. As long as you have a way of translating the JSON you receive into the desired CRUD operations, 

SCIM doesn’t even really mean you have to support hard-deleting users or their data. You should set clear expectations with your customers, but it’s usually sufficient from your customer’s perspective that de-provisioning a user results in their account appearing no longer to exist. If that simply means adding some boolean column in your database that looks like IS_DELETED, that’s probably fine.

SCIM doesn’t require real-time updates. In practice, it’s usually fine if you’re processing updates every few hours. Many companies’ identity providers can’t support real-time updates anyway. 

# How SCIM works at a (minimally) technical level
Earlier, I mentioned that SCIM just performs CRUD operations via JSON. We should take that relatively literally. SCIM will only ever handle creating, reading, updating, and deleting records.

To do so, SCIM maps pretty familiar HTTP verbs onto these CRUD tasks. We’ll need to support GET and POST, as you would expect. We’ll also need to spend time thinking about PUT, PATCH, and DELETE, which can get annoying. 

There’s something really important to bear in mind as we venture a little deeper into SCIM here. If your customer wants your software to hook into their identity provider, your software becomes the server – and your customer’s identity provider becomes the client. This might feel a little weird at first. After all, your customer’s identity provider stores the data you need. But it should make sense as we go.

## Client/server relationship and authentication in SCIM
For any given SCIM operation, your customer’s identity provider will send one or more requests to your software. You need to process the request correctly, then you need to respond in a manner that the identity provider expects and understands. 

Your software will play a passive role in SCIM. It will stay online and process requests as they roll in. The customer’s identity provider is the client. Your software is the server. 

Given its role as the client, your customer’s identity provider needs to authenticate itself to you. It needs to prove that it’s actually the identity provider – and not some attacker – to make the changes it’s requesting. (It would be really bad if anyone could come along and provision users!)

We have a few different ways of authenticating SCIM clients, but bearer tokens are the most widely-supported option. You as the server need to generate a secret, share it with your customer, and have the customer’s identity provider present that secret in HTTP headers when it makes requests. You'll consider the presentation of a valid bearer token to be sufficient proof of identity and, consequently, you'll honor any HTTP request that correctly presents a valid bearer token.

## The data that we handle in SCIM operations
SCIM’s creators built it around a generic concept that they call a *resource*. In this context, we should understand a resource to mean a particular kind of record. 

In principle, we can represent basically anything as a SCIM resource. In practice, though, we pretty much only care about two of them. SCIM has users, and it has groups. People don’t tend to use SCIM for anything else.

Users in SCIM work pretty much like you’d expect. They’re just records of the people who use your software. You can think of groups as lists of users. (We can also have groups of groups.)

## Read operations in SCIM
Let’s say you’ve just correctly configured a client/server trust relationship with your customer’s identity provider. 

Before anything else happens, your customer’s identity provider will send you an HTTP GET. It will look basically like this:

![scimget](//images.ctfassets.net/336y06gasq8n/2Pc9062CO8ZZ9oP9jeZFhJ/e686a5d948168d2bb541d08544d3ed38/scimget.png)

All the identity provider does here is to hit a given */Users* endpoint – in this case with a *userName* query parameter. It’s effectively asking here, *tell me what data you have for creed.bratton@example.com*. You’ll reply with a standard response code and some JSON. 

In this case, we don’t have any data for Creed, so we’ll respond with a status code 200 and the following JSON:

```json
{
    "itemsPerPage": 1,
    "resources": [],
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:User"
    ],
    "startIndex": 1,
    "totalResults": 0
}
```

Notice that we’re using this schemas property here to reference ``` urn:ietf:params:scim:schemas:core:2.0:User ```. We’re just referencing the built-in concept of users from the SCIM spec. 

## Creation operations in SCIM
The identity provider sees that we don’t have any data for Creed yet – based on the JSON we sent back – and so it instructs us to create a record. 

To do so, it will use an HTTP POST with the following request body:

```json
{
    "name": {
        "familyName": "Bratton",
        "givenName": "Creed"
    },
    "userName": "creed.bratton@example.com"
}
```

We just take this JSON and use our preferred method of creating a user record for Creed in our backend.

## Update operations in SCIM
Updates in SCIM will use either HTTP PUT or HTTP PATCH, depending on the identity provider. Some identity providers tend only to use PUT. Others tend only to use PATCH. It’s kind of chaotic. 

PUT operations in SCIM are pretty simple. They basically communicate: replace this user’s data with the data I’m showing you here. For example, Okta might send the following PUT request:

```http
PUT /scim/v2/Users/23a35c27-23d3-4c03-b4c5-6443c09e7173 HTTP/1.1
User-Agent: Okta SCIM Client 1.0.0
Authorization: <Authorization credentials>

{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
    "id": "23a35c27-23d3-4c03-b4c5-6443c09e7173",
    "userName": "test.user@okta.local",
    "name": {
        "givenName": "Another",
        "middleName": "Excited",
        "familyName": "User"
    },
    "emails": [{
        "primary": true,
        "value": "test.user@okta.local",
        "type": "work",
        "display": "test.user@okta.local"
    }],
    "active": true,
    "groups": [],
    "meta": {
        "resourceType": "User"
    }
}
```

You as the server will just look for the test.user@okta.local user data and replace it. Not too bad!

PATCH requests in SCIM can be a little more complicated. PATCH represents a partial update, whereas PUT represents a complete replacement. Here’s an example PATCH from the SCIM specification: 

```
PATCH /Groups/acbf3ae7-8463-...-9b4da3f908ce
Host: example.com
Accept: application/scim+json
Content-Type: application/scim+json
Authorization: Bearer h480djs93hd8
If-Match: W/"a330bc54f0671c9"

{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0"], 
    "Operations":[{ 
            "Op":"add", 
            "Path":"members", 
            "Value":[{ 
                    "display": "Babs Jensen",
                    "$ref": "https://example.com/v2/Users/2819c223...413861904646",
                    "Value": "2819c223-7f76-453a-919d-413861904646" 
                }
            ]
        }
    ]
} 

```

Notice the `Operations` array here. The SCIM specification allows PATCH operations to add, remove, or replace data. This turns out to be a little complicated. (More on this later). 

## Delete operations in SCIM

According to the SCIM specification, the identity provider should send an HTTP DELETE request, something like the following:

```
DELETE /Users/2819c223-7f76-453a-919d-413861904646
Host: example.com
Authorization: Bearer h480djs93hd8
If-Match: W/"c310cd84f0281b7"
```

This is sometimes how things work, but it’s not how things always work in practice.

For example, Okta doesn’t want to use DELETE. Instead, they PUT or PATCH a record such that the active property gets set to False.

# Is it a good idea to build SCIM?
## The SCIM specification is basically good, but has some subtle details
We really like the SCIM specification. Compared to other standards (looking at you, SAML), SCIM makes a lot of sense. It’s conceptually pretty simple, and it doesn’t come with major design flaws. 

It does have some subtle quirks, though. I’ll mention just a few here.

As I mentioned earlier, PATCH can get a bit complicated. You have to handle a bunch of different kinds of operations to support PATCH. Don’t worry about the content – but here’s an excerpt from the SCIM spec on how PATCH’s add operation is supposed to work:

>The result of the add operation depends upon what the target location
   indicated by "path" references:

>If omitted, the target location is assumed to be the resource
      itself.  The "value" parameter contains a set of attributes to be
      added to the resource.

> If the target location does not exist, the attribute and value are
      added.

> If the target location specifies a complex attribute, a set of
      sub-attributes SHALL be specified in the "value" parameter.

> If the target location specifies a multi-valued attribute, a new
      value is added to the attribute.

>If the target location specifies a single-valued attribute, the
      existing value is replaced.

> If the target location specifies an attribute that does not exist
      (has no value), the attribute is added with the new value.

> If the target location exists, the value is replaced.

> If the target location already contains the value specified, no
      changes SHOULD be made to the resource, and a success response
      SHOULD be returned.  Unless other operations change the resource,
      this operation SHALL NOT change the modify timestamp of the
      resource.

That’s a decent number of *if*s to support! Individually, none of these is too bad. But taken as a whole, they represent a decent chunk of code that you’ll have to write. More importantly, they represent an awful lot of tests that you’ll have to write. Yuck. 

I alluded indirectly to this other quirk earlier. SCIM stakes some strange opinions, including the expected instant messaging providers (e.g. Yahoo) associate with a built-in user attribute. It does not, however, stake a strong opinion at all regarding the meaning of *active*. Whether *active* represents a concept like *is_deleted* or something else altogether is left up to you and the identity provider. That just creates some weird, needless ambiguity. 

Open source repos like Authentik’s are just [littered with weird issues](https://github.com/goauthentik/authentik/issues/6695) resulting from ambiguity. No one seems to have all of the answers.

## Identity providers don’t always implement the spec

Some identity providers do some really weird stuff in non-compliance with the SCIM spec. And then they don’t document their weird choices properly. (I’m looking at you, Microsoft!) You just have to collide with their weird SCIM APIs in the real world and tweak your implementation as you go. 

![dog at computer](//images.ctfassets.net/336y06gasq8n/2osXgz5SVQf4hQuaPJn5oV/2c7408109a4790e2b97c575406d543ec/dog_at_computer.jpg)

Microsoft keeps a list of SCIM non-compliance issues [here](https://learn.microsoft.com/en-us/entra/identity/app-provisioning/application-provisioning-config-problem-scim-compatibility). You may notice that an issue called *Update PATCH behavior to ensure compliance (such as active as boolean and proper group membership removals)* still has a planned fix date of TBD ... on an article last updated in October 2023. 

It turns out that Microsoft’s default behavior sends a boolean value as a string:

```json
{
  "schemas": [
      "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ],
  "Operations": [
      {
          "op": "Replace",
          "path": "active",
          "value": "False"
      }
  ]
}
```

It should really be sending the below modified JSON,

```json
{
  "schemas": [
      "urn:ietf:params:scim:api:messages:2.0:PatchOp"
  ],
  "Operations": [
      {
          "op": "replace",
          "path": "active",
          "value": false
      }
  ]
}
```

You can force Microsoft to send you the proper JSON if you use a certain feature flag (`aadOptscim062020`), but that’s really not an obvious solution! You really have to dig. It's more practical just to accept that Microsoft misbehaves and modify your code accordingly. 

This sort of stuff is very time-consuming and demoralizing to resolve. 

## You probably shouldn’t implement SCIM from scratch
I really do not recommend building SCIM in-house. To be clear, you absolutely *could*. We're not exactly splitting the atom here. 

It's just that you definitely have better things to spend your time on – things that are closer to the problems your customers care most about. 

Although SCIM lacks much conceptual complexity, it comes with a bunch of annoying baggage. If you build SCIM yourself, it will become someone’s de facto job to babysit the SCIM API and debug unforeseen subtleties. Your customers will have a not-so-great experience. You will likely be very unhappy and distracted. 

This is a case where you should probably look for an off-the-shelf solution and move on.


If you're selling business software, you'll likely run into a customer that wants something called "SCIM." Here's what you need to know.

What a developer needs to know about SCIM

Here's what a software developer would need to know about the weirdest timezones that are out there.

Australia/Lord_Howe is the weirdest timezone

[CVE-2024-45409](https://nvd.nist.gov/vuln/detail/CVE-2024-45409) was published
on September 10, 2024. It's yet another XML signature wrapping attack, this time
affecting the main Ruby implementation of SAML. The vuln allows an attacker log
in as any arbitrary user of the affected system.

This attack keeps coming up
[again](https://lists.w3.org/Archives/Public/public-xmlsec/2009Nov/att-0019/Camera-Ready.pdf)
and [again](https://www.cve.org/CVERecord?id=CVE-2020-5390), and it keeps
affecting huge swaths of the internet --- this time,
[GitLab](https://about.gitlab.com/releases/2024/09/17/patch-release-gitlab-17-3-3-released/#saml-authentication-bypass)
and much of the Ruby ecosystem --- at a time.

Here's what this issue is, why it keeps happening, and what we can do about it.

# XML Signature Wrapping

XML signatures are the year 2000's answer to
[JWTs](https://en.wikipedia.org/wiki/JSON_Web_Token). In 2024, JWTs are a very
common answer to "I need to sign some data and send it over the internet". It's
not a perfect spec, but it's workable.

XML signatures do the same thing, but every conceivable step is much more
complicated.

All an XML signature does is let you cryptographically sign an XML document.
Same thing as what JWTs do with `alg: "RS256"` (no `ES256`, because remember:
the year is 2000).

There is exactly one sane way to cryptographically sign data:

1. You take your message, and convert it to bytes
2. You sign the bytes, which produces some more bytes
3. You transmit two things: the message-bytes from (1), and the signature-bytes from (2)
4. [Don't get cute](https://en.wikipedia.org/wiki/KISS_principle).

Steps 1-3 is what JWT does. It does step (3) by separating the message and the
signature with a period (`.`), which works because it also base64s the message
and the signature, and `.` can't appear in base64. People hate on JWT because it
forgot about (4); it's part of an overarching attempt to standardize all of
crypto under something called
[JOSE](https://datatracker.ietf.org/group/jose/documents/) (and
[COSE](https://datatracker.ietf.org/doc/html/rfc8152)), a bad idea. But overall
they're pretty good. They work. You can mostly ignore the overreach on the part
of the spec authors.

XML Signatures takes a different approach. Instead, it:

1. Lets you sign *subsets* of a message,
2. Or none of the message at all,
3. Because instead of sending a signature accompanying your message, you *edit the very message you're signing* to sprinkle in some `<ds:Signature>` elements,
4. Each of which sign a different
   subset of the message. A `ds:Signature` uses a URI to point to other parts of
   the message, and say "here's a signature for that part of the message"

If you ignore the XML-ness of it all, it's the equivalent of signing `{"email":
"bob@company.com"}` by modifying it to be:

```json
{
   "email": "bob@company.com", 
   "__sig": {
      "uri": "/email", 
      "sig": "... signature for the string bob@company.com ..."
   }
}
```

This is a bad idea. It introduces the need for some "signature discovery" step,
where you search through the document for signatures (`__sig` in my JSON
example; `<ds:Signature>` elements in XML signatures). It basically begs
engineers to do this:

```python
def validate_xml(xml_document):
    for signature in find_xml_signature_elements(xml_document):
        element = resolve_uri(signature["SignedInfo"]["Reference"]["URI"], xml_document)
        verify_signature(element, signature["SignatureValue"]
```

Note that this doesn't actually *do* anything if the document doesn't have any
signature at all.

People write a ton of bugs related to this "signature discovery" step. Every
such bug is what they call a "XML Signature Wrapping" attack; someone wrote some
tricky XML that makes your code lose track of what's actually being signed.

To anticipate the obvious suggestion: no, sadly you can't just check whether the
top-level XML document is signed, because that's not how SAML does it (more
later), and SAML is the only reason people do XML Signatures (again, more
later).

So you instead in practice have people adapting their previous code to make sure
that the part of the message they care about is, in fact, signed: 

```python
def validate_xml(xml_document, uri_checklist):
    checked_uris = []
    for signature in find_xml_signature_elements(xml_document):
        element = resolve_uri(signature["SignedInfo"]["Reference"]["URI"], xml_document)
        verify_signature(element, signature["SignatureValue"]
        checked_uris.append(signature["SignedInfo"]["Reference"]["URI"])

    for uri in uri_checklist:
        if uri not in checked_uris:
            throw MissingSignatureError()
```

There are a million ways this goes wrong, but here's the one `ruby-saml` ran
into: there's nothing that guarantees the `URI` the signature points to is
unique.

So what you could do is take a legitimate message, and just stick some other
stuff into the message, reusing the same `URI`. And then hope your victim's code
will get confused as to what it just signed.

Something like this:

```xml
<Document>
    
    <ImportantStuff>
        <Message id="dead[...]beef">
            <Email>eve@evil.com</Email>
        </Message>
    </ImportantStuff>

    
    <Message id="dead[...]beef">
        <Email>alice@customer.com</Email>
    </Message>

    
    <Signature>
        <SignedInfo>
            <Reference URI="dead[...]beef" />
        </SignedInfo>
        <SignatureValue>... the correct signature, but for alice@customer.com ...</SignatureValue>
    </Signature>
</Document>
```

The victim code finds the signature, resolves the uri to the top-level
`Message`, but then later on would process `ImportantStuff` instead of
`Message`, if that's where the `Message` is normally placed.

It's a mess. Ruby-SAML patched this by [throwing if `resolve_uri` finds more
than one
match](https://github.com/SAML-Toolkits/ruby-saml/commit/4865d030cae9705ee5cdb12415c654c634093ae7).
But Ruby-SAML has no reliable way of validating which parts of an XML document
were signed, and so I wouldn't be surprised if there were more issues in that
codebase lurking.

# SAML is why this matters

Nobody cares about XML Signatures anymore, except in the context of SAML. SAML
is what people mean by "enterprise single-sign-on", and it works by having an
Identity Provider (Okta, Microsoft Entra, Google Workspace, etc.) send a signed
XML message to a Service Provider (a B2B SaaS product). That message typically
just contains the logging in user's email address. It's an elaborate email
address transmission protocol.

Concretely, SAML requests are a POST from your user's browser containing:

```xml
<?xml version="1.0" encoding="UTF-8"?>
<saml2p:Response>
    <saml2:Assertion ID="id2829877824622019702853127">
        <saml2:Issuer>
            http://www.okta.com/exkig8gdo63cjI4OD5d7
        </saml2:Issuer>
        <ds:Signature>
            <ds:SignedInfo>
                <ds:Reference URI="#id2829877824622019702853127">
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                n744L/[...]mDruC1H9E0Lz7sbZg==
            </ds:SignatureValue>
        </ds:Signature>
        <saml2:Subject>
            <saml2:NameID>
                ulysse.carion@ssoready.com
            </saml2:NameID>
        </saml2:Subject>
    </saml2:Assertion>
</saml2p:Response>
```

And "implementing SAML" mostly consists of:

1. "Validating" the message, with all the fraught gotchas that entails
2. Logging in the user as `ulysse.carion@ssoready.com`.

Notice how this is roughly the same shape of message that I laid out in the
previous example. I won't disclose it here because that'd be irresponsible, but
you can do the same attack. You could get me to validate the message in step
(1), but then have some other thing in the message, also with
`ID="id2829877824622019702853127"`, that I use in step (2).

To repeat it again, the core dumb idea here is that you're signing a message,
instead of signing bytes. XML Signatures interweaves cryptography and the XML
tree model into a messy knot. It's really hard to make sure the message you're
processing is the same as the bytes you verified.

# How to fix this: disregard the spec

SAML library authors need to stop being so credulous about the spec.

When a specification is a collection of security flaws, responsible engineers
disregard the specification. Responsible engineers should disregard what the
SAML and XML Signatures spec authors wrote down, and instead implement the
secure thing at its core.

Put another way, the reason XML wrapping attacks keep coming up is that people
architect their code like this:

1. `saml-ruby` calls into some
2. `xml-signatures-ruby` dependency or submodule

This seems like good, sane composition. But XML Signatures is insane. It cannot
be composed. XML Signatures can't say "yes this message is valid". What it can
say is "these N potentially-overlapping subsets of this XML document are
correctly signed" (It's actually [considerably worse than
that](https://ssoready.com/blog/engineering/xml-dsig-is-unfortunate/), but whatever). There's no
building on top of XML Signatures.

So here's the sane thing to do instead:

1. Notice that every Identity Provider in the world has practically agreed to
   shape their SAML payloads in the same shape.
2. Assume all messages shaped otherwise are invalid.
3. Disregard the `URI` in XML signatures.
4. Presume in advance that they're signing exactly the subset of the SAML
   payload they should be signing, which is also the subset of the payload
   you'll be processing later.
5. Verify *that* signature, and only that signature.

In other words: forget XML signatures. Treat it as some weird relic. Just look
at the SAML payload, and implement the de-facto protocol that has emerged.

Ignore [Postel](https://en.wikipedia.org/wiki/Robustness_principle). When it
comes to processing cryptographic signatures, loosey-goosey isn't "liberal",
it's libertine.

A very common SAML library for Ruby had a major vulnerability that affected major companies like GitLab. This is an analysis of the vulnerability and a comment on how developers can protect themselves.

Ruby-SAML pwned by XML signature wrapping attacks

A beginner-friendly guide to SAML single sign-on (SSO) for developers. Learn how SAML works, what SAML assertions and responses are, and why most teams choose to abstract it away.

Latest from Tesseral

XML Signatures are a bad idea executed even worse

What a developer needs to know about SCIM

Australia/Lord_Howe is the weirdest timezone

Ruby-SAML pwned by XML signature wrapping attacks

A Gentle Introduction to SAML