GQAdonis
commented
11 years ago Hey, there! Thanks so much for responding, Jeff! I think we can discuss the issues here and go back to CodePlex with questions that might need more interaction from the entire group (although this may prove to need change).
Here are my thoughts on security:
That is THE most important part of this design effort, and I was planning to support the configuration of security/authorization provider interfaces, building 2 into the base module code (one for OAuth and one for Basic authentication with or without SSL). This can be done using an implementation of IAuthorizationFilter that would have an enumeration of the configured IDependency-derived provider interfaces.
I will be checking in again today some code that has an ApiSettingPart/ApiSettingPartRecord defined for globally turning on and off API access and, perhaps, turning on and off various provider types for authentication and authorization.
Here is a code sample that I have used before to support Basic authentication:
public class BasicAuthenticationAttribute : AuthorizationFilterAttribute
{
public override void OnAuthorization(System.Web.Http.Controllers.HttpActionContext actionContext) {
var workContext = actionContext.ControllerContext.GetWorkContext();
var membershipService = workContext.Resolve<IMembershipService>();
var authenticationService = workContext.Resolve<IAuthenticationService>();
var userEventHandlers = workContext.Resolve<IEnumerable<IUserEventHandler>>();
var authorization = actionContext.Request.Headers.Authorization;
if (authorization != null && authorization.Scheme.ToLower().Equals("basic")) {
var credentials = Encoding.ASCII.GetString(Convert.FromBase64String(authorization.Parameter));
if (!string.IsNullOrEmpty(credentials)) {
var credentialParts = credentials.Split(new[] {':'}, 2);
if (credentialParts.Length == 2) {
var userName = credentialParts[0];
var password = credentialParts[1];
// now check for authorization...
var user = ValidateLogOn(membershipService, userName, password);
if (user != null) {
authenticationService.SignIn(user, true);
foreach (var userHandler in userEventHandlers) {
userHandler.LoggedIn(user);
}
}
else {
actionContext.Response = actionContext.ControllerContext.Request.CreateResponse(HttpStatusCode.Unauthorized);
}
}
}
}
}
private IUser ValidateLogOn(IMembershipService membershipService, string userNameOrEmail, string password)
{
bool validate = !String.IsNullOrEmpty(userNameOrEmail);
if (String.IsNullOrEmpty(password))
{
validate = false;
}
if (!validate)
return null;
var user = membershipService.ValidateUser(userNameOrEmail, password);
return user;
}
}The "Basic Authentication" provider will look something like that, but there is more to this. At some point, I would like to support the field-level configuration of what the resulting JSON will look like based on role and method of authentication (e.g., an "administrator" authenticated directly might have access to more JSON properties than a regular user authenticated via OAuth token from Facebook). This feature might be deferred to a later release, but I would hope not to box ourselves in where this is hard to add.
We will also have an IPermissionsProvider come into play. Some people should be able to make GET requests for content type definitions, content part definitions, etc. but perhaps not be able to create them via POST methods. The site administrator should be able to use the Orchard permissions infrastructure to control this in addition to role and method of authentication as previously mentioned.
An IHttpRouteProvider implementation will use the ApiPart settings (or lack of presence) to configure routes against a plain vanilla ContentApiController, which operates from a JSON API perspective, JUST like the ContentController does for assembling shapes and template processing to return HTML. It will be the same idea.
There will be a ContentTypeApiController, ContentPartApiController, and FieldApiController for "reflecting" over Orchard's set of type, part, and field definitions.
When a ContentPart has an associated strongly typed "record", I planned to use standard CLR property reflection along with custom attributes to determine how those custom record properties should be treated when it comes to building the final JArray and/or JObjects using NewtonSoft to dynamically create IQueryable results for API callers.
This way, we can support OData for all these objects as well. The construction of JSON, once again, is dependent on permissions, roles, and rules associated with authorization methods that can be extended via authorization providers.
Does that sound like a plan?
jeffolmstead
weichen55
jmgomez
sfmskywalker
NukemHill
I am excited about the work you are doing on this module as I have set up a number of API access points to Orchard and it would be nice to see something both native and generic to make it work through an interface without needing to code every time.
My one early question is how you are approaching security. On all my API access I am using the WebAPI.Hmac model with the goal of having a private key for each user. This means the username be passed in with the request then go to the user part to get their private key. It allows the information to be encrypted using a private key that only the user knows. The other nice thing is that I can apply the security via an attribute so it is not obtrusive. I would gladly contribute it to the project (both client side and server side).
I suppose oAuth could also be considered (don't know exactly how that works out but I am sure someone else does).
Possibly the security could be a plugin (via interface)? This way other developers could implement the interface to append their own security scenarios they need.
I would just like to see a scenario where the users password is never streamed over the wire as not everyone I work with uses https.
Finally, is there a better place to dialogue other than the issue section?