# REST Web Service Security

**URL:** <https://www.ruby-forum.com/t/rest-web-service-security/143265>\
**Category:** Rails\
**Created:** [July 16, 2008, 9:42pm UTC](https://www.ruby-forum.com/t/rest-web-service-security/143265 "2008-07-16T21:42:19Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mark\_ASRichman](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/13edae/32.png) [@Mark\_ASRichman](https://www.ruby-forum.com/u/Mark_ASRichman)\
**Post date:** [July 16, 2008, 9:42pm UTC](https://www.ruby-forum.com/t/rest-web-service-security/143265/1 "2008-07-16T21:42:19Z")

</div>

I am new to REST web services in Rails, but I do have a strong SOAP  
background. I’d like someone to explain the various security  
mechanisms used in REST web services (authentication and  
authorization). I doubt there is something like WS-\* for REST.  
Specifically, if I choose HTTP Basic auth vs. some token-based  
approach (either custom HTTP header or XML message element), what are  
my options? I guess this is analogous to TLS vs. Message security in  
SOAP.

I am also curious how to suppress or whitelist/blacklist certain  
attributes from being serialized as XML responses. For example, I  
don’t think sending back foreign keys by default is a good idea. It  
looks to me that the model objects are just blindly serialized as XML.  
I’d like to be educated here.

Thanks,  
Mark

---

<div class="post-metadata">

**Author:** ![Mark\_ASRichman](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/13edae/32.png) [@Mark\_ASRichman](https://www.ruby-forum.com/u/Mark_ASRichman)\
**Post date:** [July 17, 2008, 4:15pm UTC](https://www.ruby-forum.com/t/rest-web-service-security/143265/2 "2008-07-17T16:15:22Z")

</div>

Hi Mark,

> I am new to REST web services in Rails, but I do have a strong SOAP  
> background. I’d like someone to explain the various security  
> mechanisms used in REST web services (authentication and  
> authorization). I doubt there is something like WS-\* for REST.  
> Specifically, if I choose HTTP Basic auth vs. some token-based  
> approach (either custom HTTP header or XML message element), what are  
> my options? I guess this is analogous to TLS vs. Message security in  
> SOAP.

You are right. As-is there is no predefined scheme for doing REST-based  
security like the WS-\* range does. An open standard for doing identity  
and security management is something that REST lacks, as far as I know.

As for authentication: HTTP authentication using restful\_authentication  
works great. Next comes authorization. There’s a lot of good plugins out  
there handling role-based authorization.

What you need to think about while doing RESTful development is how to  
handle identities over requests. If you’re able to maintain a session  
over subsequent requests from the callers side, then that’d probably be  
the easiest. If the RESTful Rails app can determine the role of a caller  
and derive it’s access rights, then you can just serve up the accessible  
content.

Other options include tried-and-true schemes like challenge/response  
systems and certificate-based payload encryption. It’s all possible,  
it’s just that there’s no established standard.

> I am also curious how to suppress or whitelist/blacklist certain  
> attributes from being serialized as XML responses. For example, I  
> don’t think sending back foreign keys by default is a good idea. It  
> looks to me that the model objects are just blindly serialized as XML.  
> I’d like to be educated here.

The to\_xml methods can do this by default. If you need more complex XML  
renderings then you can create your own XML view builders.

–  
Roderick van Domburg

> **[De domeinnaam Nedforce.nl is te koop.](http://www.nedforce.nl)**
>
> Deze mooie domeinnaam kan al over een paar minuten van jou zijn. Betalen gaat eenvoudig en vertrouwd via iDEAL. Direct na de betaling ontvang je de verhuiscode per e-mail en kun je aan de slag.

---

<div class="post-metadata">

**Author:** ![Mark\_ASRichman](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/13edae/32.png) [@Mark\_ASRichman](https://www.ruby-forum.com/u/Mark_ASRichman)\
**Post date:** [July 17, 2008, 8:23pm UTC](https://www.ruby-forum.com/t/rest-web-service-security/143265/3 "2008-07-17T20:23:00Z")

</div>

Roderick,

I use restful\_authentication, but it just does a lookup on  
params[:login] and [:password] in the request. I’ve seen many REST  
APIs that require an API key or token in the HTTP header itself, as  
opposed to a request param. How would I parse this out in a  
before\_filter? I’m guessing the before\_filter would go in  
ApplicationController for authentication, and then another filter(s)  
in other controllers for authorization.

If I have a client to a service that requires the same, how do I set  
the API key in the HTTP header of the request?

I’ve been working with SOAP for a long time (http://  
[Publications | Mark Richman](http://www.markrichman.com/publications/)). I feel like I’m re-learning and re-  
inventing a lot with REST now that we’ve rolled the whole web services  
stack back to 1999…which isn’t a bad thing 🙂

Thanks,  
Mark

On Jul 17, 10:15 am, Roderick van Domburg \<rails-mailing-l…@andreas-

---

<div class="post-metadata">

**Author:** ![Mark\_ASRichman](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/13edae/32.png) [@Mark\_ASRichman](https://www.ruby-forum.com/u/Mark_ASRichman)\
**Post date:** [July 17, 2008, 11:13pm UTC](https://www.ruby-forum.com/t/rest-web-service-security/143265/4 "2008-07-17T23:13:08Z")

</div>

InfoQ looks like a great resource…thanks!

Seems like the issue today is not so much SOAP vs. REST, but the  
backlash against interface/contract based programming in general. This  
raises the issue of versioning/deprecating interfaces (or resources).

For me, I see issues with service discovery (a la WSDL) with REST, as  
there is no way that I can see for a consumer to learn a REST service’s  
API without referring to human-readable documentation. With SOAP, we  
have the ABCs (address-binding-contract). With REST, the A and B are  
implicit, which leaves C.

What I’d like to see happen for REST to mature is a simple way to  
describe the exchange of documents (messages), and not just serialize  
objects, which is all the SOAP/WSDL/XSD mess really describes. In the  
end, I guess REST is about semantics and SOAP is about syntax.

Thanks,  
Mark

---

<div class="post-metadata">

**Author:** ![Mark\_ASRichman](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/13edae/32.png) [@Mark\_ASRichman](https://www.ruby-forum.com/u/Mark_ASRichman)\
**Post date:** [July 17, 2008, 8:52pm UTC](https://www.ruby-forum.com/t/rest-web-service-security/143265/5 "2008-07-17T20:52:53Z")

</div>

Hey Mark,

> I use restful\_authentication, but it just does a lookup on  
> params[:login] and [:password] in the request. I’ve seen many REST  
> APIs that require an API key or token in the HTTP header itself, as  
> opposed to a request param. How would I parse this out in a  
> before\_filter? I’m guessing the before\_filter would go in  
> ApplicationController for authentication, and then another filter(s)  
> in other controllers for authorization.

You are entirely right.

Note that restful\_authentication also supports HTTP basic auth out of  
the box using the :require\_login before filter. You could look into  
extending or overriding it.

> If I have a client to a service that requires the same, how do I set  
> the API key in the HTTP header of the request?

If the client is a Rails-based app then it’s easy to manipulate HTTP  
headers like so:  
[http://api.rubyonrails.org/classes/ActionController/AbstractRequest.html#M000794](http://api.rubyonrails.org/classes/ActionController/AbstractRequest.html#M000794)

> I’ve been working with SOAP for a long time (http://  
> [Publications | Mark Richman](http://www.markrichman.com/publications/)). I feel like I’m re-learning and re-  
> inventing a lot with REST now that we’ve rolled the whole web services  
> stack back to 1999…which isn’t a bad thing 🙂

I can heartily recommend [http://www.infoq.com](http://www.infoq.com) for keeping up to date on  
the state of the art in web services and architectures - REST and SOAP  
alike. It has a couple of good feature articles on SOAP vs. REST and  
RESTful security as well.

–  
Roderick van Domburg

> **[De domeinnaam Nedforce.nl is te koop.](http://www.nedforce.nl)**
>
> Deze mooie domeinnaam kan al over een paar minuten van jou zijn. Betalen gaat eenvoudig en vertrouwd via iDEAL. Direct na de betaling ontvang je de verhuiscode per e-mail en kun je aan de slag.

---

<div class="post-metadata">

**Author:** ![Mark\_ASRichman](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/13edae/32.png) [@Mark\_ASRichman](https://www.ruby-forum.com/u/Mark_ASRichman)\
**Post date:** [July 18, 2008, 9:33am UTC](https://www.ruby-forum.com/t/rest-web-service-security/143265/6 "2008-07-18T09:33:59Z")

</div>

Hi Mark,

> Seems like the issue today is not so much SOAP vs. REST, but the  
> backlash against interface/contract based programming in general. This  
> raises the issue of versioning/deprecating interfaces (or resources).
> 
> For me, I see issues with service discovery (a la WSDL) with REST, as  
> there is no way that I can see for a consumer to learn a REST service’s  
> API without referring to human-readable documentation. With SOAP, we  
> have the ABCs (address-binding-contract). With REST, the A and B are  
> implicit, which leaves C.
> 
> What I’d like to see happen for REST to mature is a simple way to  
> describe the exchange of documents (messages), and not just serialize  
> objects, which is all the SOAP/WSDL/XSD mess really describes. In the  
> end, I guess REST is about semantics and SOAP is about syntax.

I agree. REST architecture is nice when you know and can influence the  
interface yourself. Definition languages will be important to raise it  
to the “ubiquitous” web service status. There’s stuff happening on this  
front: WADL is one stab at it.

The “vs” in my previous message isn’t so much a question of “which is  
better” but rather “which is more suitable” - which is a question any  
software architect should ask himself. Sometimes it’ll be REST.  
Sometimes it’ll be SOAP.

Things are bound to change as domain-specific WSDL’s are adopted and  
REST web services will mature into contract specifics. I’m looking  
forward how REST services will tackle it without getting entangled in  
specification and registration messes that is called SOAP.

It’s interesting to converse with someone who is well-versed in SOAP –  
I’d love to hear it when you find out more through your REST journeys!

–  
Roderick van Domburg

> **[De domeinnaam Nedforce.nl is te koop.](http://www.nedforce.nl)**
>
> Deze mooie domeinnaam kan al over een paar minuten van jou zijn. Betalen gaat eenvoudig en vertrouwd via iDEAL. Direct na de betaling ontvang je de verhuiscode per e-mail en kun je aan de slag.
