MicrosoftGraphAuthProvider does not respect [Authenticate("microsoftgraph")] attribute - microsoft-graph-api

We have implemented the MicrosoftGraphAuthProvider and it is all set up correctly as we have added an endpoint to output the authorized user's credentials using the following:
if (!IsAuthenticated) return null;
var session = this.Request.GetSession(true);
return session.ToJson();
This outputs my user, with the provider as microsoftgraph. Great, everything as expected.
However, when we add the authorization attribute:
[Authenticate("microsoftgraph")]
It returns a 401 and acts as if we are not logged in at all. All ss-id and ss-pid are sent in headers correctly, but it still returns a 401.
However, elsewhere in the system, we are using this same method to limit to API key auths
[Authenticate("apikey")]
We currently have 3 IAuthProviders loaded into the API.
Is there an issue in the provider itself or is there a different methodology behind limiting a service to microsfoftgraph provider?

When you use an Auth Provider name, e.g:
[Authenticate("microsoftgraph")]
It tells ServiceStack to check with that registered AuthProvider to determine whether it thinks user is Authenticated which it does by calling its IsAuthorized() method, MicrosoftGraphAuthProvider doesn't have one defined so it uses its base OAuthProvider implementation:
public override bool IsAuthorized(IAuthSession session, IAuthTokens tokens, Authenticate request = null)
{
if (request != null)
{
if (!LoginMatchesSession(session, request.UserName)) return false;
}
return session != null && session.IsAuthenticated && !string.IsNullOrEmpty(tokens?.AccessTokenSecret);
}
You can override this behavior by either overriding the AuthProvider and implementing IsAuthorized or by overriding your Custom UserSession and overriding IsAuthorized(provider), e.g:
public class MyUserSession : AuthUserSession
{
public override bool IsAuthorized(string provider)
{
if (provider == MicrosoftGraphAuthProvider.Name)
return IsAuthenticated && AuthProvider == provider;
return base.IsAuthorized(provider);
}
}

Related

How do I get the information of the user I deleted from JPA Auditing?

I'm using JPA Auditing.
And because I'm using Spring-Security, I'm automatically entering the information of the logged-in user using AuditorAware.
(Using #lastModifiedByAnnotation)
The current situation is that when registering and modifying, the information of the currently logged-in user is well included, but if you delete it, the NULL value is included.
Even if I delete it, I want to let the deleted user enter lastModifiedBy, what should I do?
#Configuration
public class JpaAuditConfig implements AuditorAware<String> {
#Override
public Optional<String> getCurrentAuditor() {
Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
if (authentication == null || !authentication.isAuthenticated()) {
return null;
}
return Optional.ofNullable(((Member) authentication.getPrincipal()).getName());
}
}

Dart Aqueduct server basic authorization

I'm learning about how authentication works using the Aqueduct framework.
In my channel.dart file I have a route:
router
.route('/protected')
.link(() => Authorizer.basic(validator))
.link(() => ProtectedController());
But I don't know how to create the validator. In the docs I see that I can make a custom Authorizer without using an AuthServer. The code example is this:
class BasicValidator implements AuthValidator {
#override
FutureOr<Authorization> validate<T>(AuthorizationParser<T> parser, T authorizationData, {List<AuthScope> requiredScope}) {}
var user = await userForName(usernameAndPassword.username);
if (user.password == hash(usernameAndPassword.password, user.salt)) {
return Authorization(...);
}
return null;
}
}
I'd like to make a basic working example, but this is the closest that I could get:
class BasicValidator implements AuthValidator {
#override
FutureOr<Authorization> validate<T>(AuthorizationParser<T> parser, T authorizationData, {List<AuthScope> requiredScope}) {
final validUsername = 'bob';
final validPassword = 'password123';
// How do I get the parsed username?
// How do I get the parsed password?
if (parsedUsername == validUsername && parsedPassword == validPassword) {
// How do I create an Authorization?
return Authorization(...);
}
return null;
}
// What is this?
#override
List<APISecurityRequirement> documentRequirementsForAuthorizer(APIDocumentContext context, Authorizer authorizer, {List<AuthScope> scopes}) {
return null;
}
}
Could anyone show me a basic working example of Basic authorization validator?
authorizationData is an instance of AuthBasicCredentials when using Authorizer.basic. An object of this type has username and password fields derived from parsing the 'Authorization' header from a request.
An Authorization object is a container for data related to the authorized resource owner (such as their user ID). It is used by subsequent controllers to control authorization without having to look up the authorized user again; you should populate it with any authorization information you have available.
documentRequirementsForAuthorizer is used during OpenAPI document generation. An Authorizer that uses your validator will encode the returned security requirements into the OpenAPI operations being secured.
See also http://aqueduct.io/docs/auth/authorizer/#using-authorizers-without-authserver.
#override
FutureOr<Authorization> validate<T>(AuthorizationParser<T> parser, T authorizationData, {List<AuthScope> requiredScope}) {
final validUsername = 'bob';
final validPassword = 'password123';
final credentials = authorizationData as AuthBasicCredentials;
if (credentials.username == validUsername
&& credentials.password == validPassword) {
return Authorization(
null, // no client ID for basic auth
await getUserIDFromUsername(validUsername), // This is your problem to solve
this, // always this
credentials: credentials // if you want to pass this info along
);
}
return null;
}

Changes to cookie domain for outgoing responses ignored for ServiceStack requests

I have a multi-tenant website (e.g. several different sites, each with it's own domain, all in the same project, separated using MVC areas), where the authentication cookie has the domain manually set when the user logs in so that it is available to all subdomains (but not the various other sites in the project, this is not an SSO).
So a user logins a x.foo.com, the cookie domain is set for foo.com, so that it also works at y.foo.com and z.foo.com. However, because of the other domains being served from the same project the auth cookie domain cannot be set in the web.config in the usual manner, instead it is set manually when the user logins in like so:
public HttpCookie GetAuthenticationCookie(string username)
{
var cookieDomain = UrlHelper.GetTopAndSecondLevelDomain();
var authenticationCookie = FormsAuthentication.GetAuthCookie(username, false);
authenticationCookie.Domain = cookieDomain;
return authenticationCookie;
}
This works fine, but of course can cause a problem when the cookie is automatically refreshed for sliding expiration. So we have an HTTP module which is hooked into the PostRequestHandlerExecute event of our MVC app to look for auth cookies that were set into the response during the request, and overriding the domain:
public class AuthenticationCookieDomainInterceptorModule : IHttpModule
{
public void Init(HttpApplication context)
{
context.PostRequestHandlerExecute += UpdateAuthenticationCookieExpiry;
}
private void UpdateAuthenticationCookieExpiry(object sender, EventArgs e)
{
var app = (HttpApplication) sender;
var cookieDomain = UrlHelper.GetTopAndSecondLevelDomain();
var authenticationCookie = GetCookieFromResponse(app.Context.Response, FormsAuthentication.FormsCookieName);
if (authenticationCookie != null)
{
if (authenticationCookie.Domain == null || !string.Equals(authenticationCookie.Domain, cookieDomain, StringComparison.InvariantCultureIgnoreCase))
{
authenticationCookie.Domain = cookieDomain;
}
}
}
private HttpCookie GetCookieFromResponse(HttpResponse response, string cookieName)
{
var cookies = response.Cookies;
for (var i = 0; i < cookies.Count; i++) {
if (cookies[i].Name == cookieName)
{
return cookies[i];
}
}
return null;
}
}
This is also works fine unless the request is to our ServiceStack front end which we use to handle our AJAX requests. In that case the module fires as normal, picks up the cookie if its been set, changes the domain as it should, but when the response is sent back to the client the changes to the cookie are ignored.
Is there any reason why the cookie changes wouldn't be saved to the response in this scenario? My guess would be something to do with the fact ServiceStack uses an HttpHandler to hook in the request cycle in the first place, so we are not going through the normal MVC request life-cycle.

Extend AuthorizeAttribute to detect logged in non-user (How to handle user authorization)

Environment: ASP.NET MVC 4, Visual Studio 2012
The [Authorize] attribute verifies that the user has a valid login cookie, but it does NOT verify that the user actually exists. This would happen if a user is deleted while that user's computer still holds the persisted credentials cookie. In this scenario, a logged-in non-user is allowed to run a controller action marked with the [Authorize] attribute.
The solution would seem to be pretty simple: Extend AuthorizeAttribute and, in the AuthorizeCore routine, verify that the user exists.
Before I write this code for my own use, I'd like to know if someone knows of a ready-to-go solution to this gaping hole in the [Authorize] attribute.
You need a special authentication global action filter.
Solution to your problem is the following. You have to introduce the global action filter that will be executed before controller action is invoked. This event is named OnActionExecuting. And within this global action filter you can also handle the scenario that user have a valid auth cookie, but does not exists in persistence (DB) anymore (and you have to remove its cookie).
Here is the code example to get an idea:
public class LoadCustomPrincipalAttribute : ActionFilterAttribute
{
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
CustomIdentity customIdentity;
if (HttpContext.Current.User.Identity.IsAuthenticated)
{
UserData userData = UserRepository.GetUserByName(HttpContext.Current.User.Identity.Name);
if (userData == null)
{
//TODO: Add here user missing logic,
//throw an exception, override with the custom identity with "false" -
//this boolean means that it have IsAuthenticated on false, but you
//have to override this in CustomIdentity!
//Of course - at this point you also remove the user cookie from response!
}
customIdentity = new CustomIdentity(userData, true);
}
else
{
customIdentity = new CustomIdentity(new UserData {Username = "Anonymous"}, false);
}
HttpContext.Current.User = new CustomPrincipal(customIdentity);
base.OnActionExecuting(filterContext);
}
}
Hope it helps to you!
Do not forget to register this action filter as a global one. You can do this like:
private static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new LoadCustomPrincipalAttribute());
}
Just to add this. Leave alone AuthorizeAttribute. It should work as it was meant. It simply check the HttpContext.Current.User.Identity.IsAuthenticated == true condition. There are situations that you would need to overide it, but this is not the one. You really need a proper user/auth handling before even AuthorizeAttribute kicks in.
Agreed with Peter. Here is what I did for an AngularJs app. Create an attribute that checks the lockout date. Change YourAppUserManager out with the correct one.
public class LockoutPolicyAttribute : ActionFilterAttribute
{
public override async Task OnActionExecutingAsync(HttpActionContext actionContext, CancellationToken cancellationToken)
{
if (HttpContext.Current.User.Identity.IsAuthenticated)
{
var now = DateTime.UtcNow;
var currentUserId = Convert.ToInt32(HttpContext.Current.User?.Identity?.GetUserId());
var user = await HttpContext.Current.GetOwinContext().GetUserManager<YourAppUserManager>().FindByIdAsync(currentUserId);
if (user?.LockedOutUntil >= now)
{
actionContext.Response = actionContext.Request.CreateErrorResponse((HttpStatusCode)423, "Account Lockout");
return;
}
}
base.OnActionExecuting(actionContext);
}
}
Then have an AngularJs intercept service for status code 423 to redirect to login page.
switch (response.status) {
case 423: //Account lockout sent by the server.
AuthService.logOut();
window.location.href = '/login';

Custom Authorize attribute HttpContext.Request.RawUrl unexpected results

We're building an application that is a Silverlight client application, but we've created an MVC controller and a few simple views to handle authentication and hosting of the Silverlight control for this application. As part of the security implementation, I've created a custom Authorization filter attribute to handle this, but am getting some unexpected results trying to properly handle redirection after authentication.
For example, our Silverlight application's navigation framework allows users to deep-link to individual pages within the application itself, such as http://myapplicaton.com/#/Product/171. What I want, is to be able to force a user to login to view this page, but then successfully redirect them back to it after successful authentication. My problem is with getting the full, requested URL to redirect the user to from within my custom authorization filter attribute class.
This is what my attribute code looks like:
public class RequiresAuthenticationAttribute : FilterAttribute, IAuthorizationFilter
{
protected bool AuthorizeCore(HttpContextBase httpContext)
{
var cookie = Cookie.Get(SilverlightApplication.Name);
if (SilverlightApplication.RequiresLogin)
{
return
((cookie == null) ||
(cookie["Username"] != httpContext.User.Identity.Name) ||
(cookie["ApplicationName"] != SilverlightApplication.Name) ||
(Convert.ToDateTime(cookie["Timeout"]) >= DateTime.Now));
}
else
return false;
}
public void OnAuthorization(AuthorizationContext filterContext)
{
if (filterContext != null && AuthorizeCore(filterContext.HttpContext))
{
var redirectPath = "~/login{0}";
var returnUrl = filterContext.HttpContext.Request.RawUrl;
if (string.IsNullOrEmpty(returnUrl) || returnUrl == "/")
redirectPath = string.Format(redirectPath, string.Empty);
else
redirectPath = string.Format(redirectPath, string.Format("?returnUrl={0}", returnUrl));
filterContext.Result = new RedirectResult(redirectPath);
}
}
}
So in this case, if I browse directly to http://myapplicaton.com/#/Product/171, in the OnAuthorize method, where I'm grabbing the filterContext.HttpContext.Request.RawUrl property, I would expect it's value to be "/#/Product/171", but it's not. It's always just "/". Does that property not include page level links? Am I missing something?
The # sign in URLs (also called the fragment part of an URL) is only used by browsers to navigate between history and links. Everything following this sign is never sent to the server and there's no way to get it in a server side script.

Resources