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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 http://www.nedforce.nl -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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:// > 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 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 http://www.nedforce.nl -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 http://www.nedforce.nl -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---