I have a web service that accepts CAS proxy tickets over HTTP Basic authentication headers via Spring Security. How do I perform integration testing with my client since there seems to be no programmatic way to fetch CAS tickets?
Since the CAS setup is one of the more tricky aspects of the project configuration I really need that to be part of our automated integration tests but I have hit a roadblock.
You be interested in the CAS RESTful API: https://wiki.jasig.org/display/CASUM/RESTful+API
The RESTful API follows the same basic protocol as the original CAS2 protocol, augmented with some additional well-defined resource urls. This is particularly helpful for applications that need to programmatically access CAS.
Hope this helps.
Related
We have just started splitting our monolith into services. We are going to extract the authentication/authorization service out of the monolith first. Now we have a choice - API Gateway to provide authentication vs a standalone service (Like IdentityServer4 for example).
Our auth scenarios are pretty broad - web app, mobile apps, internal tools, Oauth1 that needs to be deprecated, some hand-written API authentication.
I'm leaning towards the separate service approach, because of pros:
We can deploy/scale auth and gateway separately
We can swap gateway for another one easier
Auth server is open source and written in familiar language, easier for us to undestand - customizing it is likely to be easier
But the Cons I can see:
More moving parts
We will need to integrate Auth Server and Gateway that may be hard
I wonder what are other pros/cons of both approaches that I'm missing?
I am currently in the process of building RESTful web services using Jersey framework as a backend (for an Ipad\Iphone application) using Java, at the POINT I was trying to figure out a security( Authentication and Authorization) implementation of my the API, I came across Basic, digest and Oauth but at the point as my APIs are still not fully developed so I think Oauth seems to be a bit of an overkill to me...
My question is though Apache Shiro looks easy to grasp and start with is something that can usedfor securing RESTful web services like in the long run as my APIs logic grows?
Shiro is very customizable. It provides interfaces for doing your Authentication and Authorization. If you ever need to change your authentication from Basic to Oauth, all you have to do is implement a new class and plug it in.
The interfaces to look into are Realm, AuthenticatingRealm, AuthorizingRealm, Subject, AuthenticationToken and SimpleAuthorizationInfo.
I wanted to know how to can i protect a resource on a webserver using REST API.Like for example i want to access http://www.xyz.com/folder/impresource.doc but before accessing that i have to be authenticated. The thing is i am try to create a simple mobile client to authenticate with a rest service and then be able to access the resource.
I would appreciate a good example explaining how it can be done Thanks :)
It would be nice if i could get an example in php.
You implement a web service (be it REST, or be it SOAP) in some programming language (for example, Java or C#) running in some "container" (for example, IIS/.Net or Tomcat).
The layer below REST (for example, the C# code you're using to implement your IIS/.Net/SOAP web service, or the Java code in your .war) is the layer where you want to write any custom access code.
Alternatively, some vendors (for example, Amazon S3) have already done this for you:
http://aws.amazon.com/s3/faqs/
Other vendors (such as Microsoft) give you a way to use their authentication infrastructure with your web service:
Secure REST Service Microsoft Azure AppFabric
In java you can use a servlet filter, which will send an error code if it does not find an authentication object in the user session and if authenticated let the request handling proceed. A very popular implementation of this approach is Spring security[http://static.springsource.org/spring-security/site/tutorial.html]
How can I secure an webservice so my clients can use it on their applications without having to fear that their api keys will be used in other applications?
Assuming that:
you're using WCF to implement
your services
You are writing some webservices for
your client, so they will host the
webservices.
Take a look at the WCF Security Guidance from P&P group: http://wcfsecurity.codeplex.com/
It helped us a lot in defining our security strategy, based on our requirements.
In summary you need to understand how your webservices will be used, what your users will be authenticated and authorized, and based on this, implement the required configuration/code changes.
I hope this helps.
Wagner.
Is there a clean way to expose a WCF REST service that requires basic authentication, but where we handle the actual validation of the username/password ourselves? It seems that when you tell WCF in config that you want to use basic authentication, it forces you to turn on basic authentication in IIS and IIS can only do basic authentication against window accounts.
The only hack we have found is to lie to WCF and tell it there is no security on the service and then do authentication outside of the WCF stack using a generic IHttpModule (which has a proprietary config file to indicate which URLs have which authentication/authorization requirements).
It seems like there should be a better way. Anyone have one?
The WCF REST Contrib library enables this functionality:
http://github.com/mikeobrien/WcfRestContrib
It also allows you to secure individual operations.
is the username and password set on the client like:
cc.ClientCredentials.UserName.UserName = ReturnUsername();
cc.ClientCredentials.UserName.Password = ReturnPassword();
Or are they embedded in the body of the REST message?
If the former, you can use a custom UserNamePasswordValidator:
http://msdn.microsoft.com/en-us/library/aa702565.aspx
If the latter, you can set the service to no security, and use a custom ServiceAuthorizationManager to validate the contents of the message:
http://msdn.microsoft.com/en-us/library/ms731774.aspx
Hope one or the other helps! I'd try to post sample code & config, but I'm # home and dont have access to code, which is all # work.
See Custom Basic Authentication for RESTful services. Pablo's approach uses the interceptor functionality that is provided via the REST starter kit to solve the problem. If you do not want to depend on the REST starter kit, then you can create your own service host and use the inteceptor functionality provided.
If you host it on IIS, using custom http module is the way to go. You can bring over the principal over to WCF side to do code access security. See HTTP Basic Authentication against Non-Windows Accounts in IIS/ASP.NET (Part 3 - Adding WCF Support). Also see Custom HTTP Basic Authentication for ASP.NET Web Services on .NET 3.5/VS 2008.
If you are not using IIS, you should be able to implement userNameAuthentication. See Finally! Usernames over Transport Authentication in WCF.
Yes absolutely there is a way. You need to configuring a custom userNamePasswordValidationMode value for your service and point it to a class with an overridden method that can inspect and validate the credentials provided. When making a RESTful call, these credentials when using Basic authentication in its proper form should be in the request header. With this custom method you can inspect the credentials and then authenticate the client to your service. No Windows accounts or domain even needed.
The nice thing is you can then take that security context to the next level and provide fine-grained authrization at the method level. You might have instances where a large pool of clients are able to access the service, but not all methods within (i.e. paid clients vs. unpaid). In this case you can also provide authorization at the method level as well if needed.
Below is a step-by-step solution (with too many steps to embed) by me that contains both the needed configuration and security required to have a complete solution. The problem is often Basic authentication is used without securing the Transport with a SSL certificate and this is bad. Make sure to follow all the steps and you will implement Basic authentication without the need of any type of Windows accounts or configuration on your WCF RESTful based service.
RESTful Services: Authenticating Clients Using Basic Authentication