It's nice that SilkierQuartz provides authentication, but if I want to perform my own custom authentication, I need to ensure the authenticated user has the correct claim since all the Silkier Controllers are annotated with [Authorize(SilkierQuartzAuthenticateConfig.AuthScheme)].
I'm not interested in using SilkierQuartzAuthenticationMiddleware because
Specifying a hardcoded username/password is ok for demos, but not for production apps
Whether or not a user has access to the Quartz dashboard should be based on their roles/permissions/policies within the app hosting SilkierQuartz
Having a custom auth Scheme is also problematic because if my app has a different scheme (and it likely will since I don't have access to SilkierQuartzAuthenticateConfig.AuthScheme) even if I add the correct claims, when I click "Sign Out" within the SilkierQuartz dashboard, it won't sign out my app's cookie, only the SilkierQuartzAuthenticateConfig.AuthScheme cookie.
I think this needs refactored to provide an easy configuration for devs that want to quickly test SilkierQuartz and complex authN/authZ for devs with standard production requirements.
That way, when a user logs out of the dashboard, they log out of the hosting app and when they log into the hosting app (or via the SilkierQuartz auth UI) they are logged in everywhere.
maikebing
commented
3 years ago
It's nice that SilkierQuartz provides authentication, but if I want to perform my own custom authentication, I need to ensure the authenticated user has the correct claim since all the Silkier Controllers are annotated with
[Authorize(SilkierQuartzAuthenticateConfig.AuthScheme)].I'm not interested in using
SilkierQuartzAuthenticationMiddlewarebecauseHaving a custom auth Scheme is also problematic because if my app has a different scheme (and it likely will since I don't have access to
SilkierQuartzAuthenticateConfig.AuthScheme) even if I add the correct claims, when I click "Sign Out" within the SilkierQuartz dashboard, it won't sign out my app's cookie, only theSilkierQuartzAuthenticateConfig.AuthSchemecookie.I think this needs refactored to provide an easy configuration for devs that want to quickly test SilkierQuartz and complex authN/authZ for devs with standard production requirements.
I believe that Policy Based Authorization that is independent of scheme would be a better option.
Developers can then supply their own handlers for the the Policy's Requirements.
That way, when a user logs out of the dashboard, they log out of the hosting app and when they log into the hosting app (or via the SilkierQuartz auth UI) they are logged in everywhere.