asp.net - Consuming assemblies enforcing claims-based authorization from console applications -

i'm introducing (into existing application) custom permissions system maps roles provided claims (coming wsfed-based owin auth in web app) permissions defined in application itself.

currently, plan permissions system directly onto thread principal.

these permissions validated:

• in web ui
• in business layer (in case of future alternative uis).

however, 1 thing unaccounted there console application running scheduled task consumes same business layer classes web app (same assembly reference). app runs under local windows user in separate domain, not have required roles (and fail authorize).

i can see few workarounds problem:

1. duplicate roles in windows machine , assign system user under console app runs.
2. modify console app explicitly add claims identity used.
3. modify permissions system have kind of override and/or inject "dud" permissions system console app.

none of these seem particularly elegant solutions. given that, question simply: there canonical approach in context of identity authorization in kind of scenario?

very interesting question no real canonical answer i'm aware of.

i go either 1 or 2, depending on situation. if going through authentication logic clients, console app client , needs have permissions stuff in system. modifying permissions system client can open security holes , sounds hack - against logic clients permissions.

now between 1 , 2 - down situation working with. if client deployed multiple times or customers, deployment simplicity hack command line app , add required claims principal there.

if command-line client private consumption , not deployed multiple times, easiest have separate domain user required permissions on user , run app user. decouple permissions app , make life easier if need change permissions on app user without code changes in command-line app.

these pure speculation , hope there other opinions.