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
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
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). 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-
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
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
I’ve been working with SOAP for a long time (http://
Publications | Mark Richman). 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 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
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