Replacing authentication in Yves - spryker

I need to replace default Yves authentication from ‘form_login’ to ‘guard’. To be more specific I need to authenticate user agains cookie issued by another application being hosted on the sibling sub-domain. Am I right saying that it is \SprykerShop\Yves\CustomerPage\Plugin\Security\CustomerPageSecurityPlugin::addFirewalls to be overridden to inject my own firewall definition with custom instance of \Symfony\Component\Security\Guard\AuthenticatorInterface ? Do I need also to override and employ \SprykerShop\Yves\CustomerPage\Plugin\Security\CustomerPageSecurityPlugin::addAuthenticationSuccessHandler and \SprykerShop\Yves\CustomerPage\Plugin\Security\CustomerPageSecurityPlugin::addAuthenticationFailureHandler or its OK to use \Symfony\Component\Security\Guard\AuthenticatorInterface::onAuthenticationSuccess and \Symfony\Component\Security\Guard\AuthenticatorInterface::onAuthenticationFailure ? What is the basic guidance for this authentication system modification?

Related

Blazor default role provider

I have set up a Blazor application in .NET Core 3.1 and I'm implementing authentication/authorization, but it is clear I just don't have a great understanding of how default authentication works.
I set up an "AuthorizeView" tag as follows, fully expecting it to fail:
<AuthorizeView Context="auth" Roles="Admin">
<Authorized>
Content
</Authorized>
<NotAuthorized>
You do not have access to this page.
</NotAuthorized>
</AuthorizeView>
but instead it works fine. I am able to see the "Content" section, despite the fact I have not set up ANY authorization. I'm assuming this defaults back to something like Windows Authentication (which is what I'm using in my Blazor app) but I'm not specifying to use AD Authorization anywhere.
Can anyone point me to where I would go, or help me understand, how this is working by default and where it is pulling this "Admin" role from?
You can control and limit access to your resources using authorization. You can control access depending on the roles of the user, claims and authorization policy.
Using the AuthorizeView above and setting the Roles attribute to "Admin", you tell Blazor that if the user belongs to the Admin role, he is authorized to access the content within Authorized element.
I guess that you've set your Blazor app to authenticate users accessing your app by selecting Windows Authentication, when creating your app, right ?
When you try to access your app, you are asked to provide your credentials which are passed from IIS (express) to your app...
Roughly speaking a Claims Principle( or Windows Principle) object is created by Blazor and passed to an object named ServerAuthenticationStateProvider as an AuthenticationState object. This object, meaning the AuthenticationState object is also provided to the AuthorizeView whose base class AuthorizeViewCore contains the logic to call the IAuthorizationService, passing it the claims principle. Now the authorization service inspect the Claims Principle object, what claims it has, what roles it has, and of course it looks for a role claim with the value "Admin", if found, true is returned, and at the end of the pipe line it is decided that you are allowed to access the restricted content.
where it is pulling this "Admin" role from
From your Windows AD if you've one or from windows user accounts, etc. Remember, you told the wizard that you want to use Windows authentication (this is my supposition, otherwise everything I've said may be wrong).
You had better go to the docs and acquaint yourself with services like AuthenticationStateProvider, ServiceAuthenticationStateProvider ,etc.

ADFS - On premises SSO Implementation

I have an Asp.Net application that communicate with ADFS(on some other Windows Server) for authentication purpose. Currently, when we navigate to application, it redirects to ADFS SSO authentication page. I followed this blog to implement SSO and have some questions here:
Can we change implementation so that it may redirect to authentication page only when I press login button ?
Can we change implementation so that only one page/URL of my application can be accessed without any authentication ?
What parameters are returned when user is authenticated and redirected back to landing page. How do we get all available parameters ?
In this blog returning things are are Value, ValueType, Subject Name, Claim Issuer and Claim Issuer type. Can I get email or username ? so that I may link that person to a client in my application.
If anyone of above is possible, how I can get it ?
The login button is part of the ADFS screen. That's by design. The sample uses WIF so you are outsourcing authentication to ADFS.
Yes - Use the "location" annotation in the web.config. refer Location Element.
The parameters that are returned are the claims configured in the claims rules. The article show "Display-Name" and UPN. If you want email, just add another row and select it from the dropdown.

Customizing CQ / AEM Authentication

What exactly do you have to do to authenticate users against an external source while accessing pages on a CQ publish instance?
From what I have read, a custom AuthenticationHandler can be used for this. The AuthenticationHandler can be configured to be called against the paths requiring authentication and inside the extractCredentials() method, the users will be authenticated against the external source and an AuthenticationInfo object will be returned.
If the supplied credentials are invalid, null would be returned from this method to indicate the same. The SlingAuthenticator will then call requestCredentials() where the user can be redirected to the login page.
Is this understanding correct? If so, what does SlingAuthenticator do with the AuthenticationInfo object returned from extractCredentials()?
In some places, having a custom LoginModule (by overriding AbstractLoginModule) is also suggested for the same purpose. Are these 2 different approaches (custom AuthenticationHandler and Loginmodule) for having custom authentication or are they used together somehow? If so, how do they interact?
And also, the concept of CUG (Closed User Group) can be used to redirect users to the login page if they don't have access to a page. Can CUG still be used with a custom auth mechanism or it only works if the users are present in CQ repository?
Any light shed on this would be much appreciated :)
Your understanding is correct. The AuthenticationInfo object ultimately contains a JCR user id -- but rather than having to use the JCR password for the user, a 3rd party service basically says "this user has authenticated successfully and can access the repository as X".
Example: you're using OpenID or SAML to verify a user is X. user X is then mapped to a user Y in the repository.
I haven't used LoginModule but from what I'm reading, that's just extending login processing for the JackRabbit repo. So, rather than using AuthenticationHandler to redirect a user to some other place and processing the response, you're plugging further down into the chain where there's already AuthenticationInfo (or something like that) being given to JackRabbit to verify and return a session for a user.
So, let's say you did successfully authenticate with OpenID but the user you're mapped to doesn't exist. You could write a login module to create the user in this case (and assign user to a default group). For instance, if user came in with a gmail id, the JCR user could be gmail_$id. And the login module, seeing the name starts with gmail, will know it's ok to create that user automatically.
As far as CUG, yes, all the above can be used in conjunction with it. Basically, if a request doesn't have access to a resource and the request hasn't been authenticated, the authentication handling system kicks in. If a user has authenticated but still doesn't have access to the resource (e.g. not part of a group that can read it), a 403 will be generated.

Track OAuth 2 provider on client page

I have the ability to login via Facebook and Google on my website. This is done using OAuth2.
I use the same redirect URL whether the user is returning from facebook or google, and pass through the provider name in the state field. Is this the recommended way to track the provider? Otherwise I do not know who to validate the token with if I do not know which provider the token comes from.
Are there other preferred methods for accomplishing this?
The state parameter should be an opaque value that cannot be guessed by an attacker since it is not protected from modifications. If you need to track state, you should refer to it by using the state parameter but that parameter itself should be randomized and/or encrypted. Storing the provider identifier in plaintext in the state parameter is not safe. Users could modify the state parameter themselves or attackers could craft an authorization request with a state value that they choose.
The way to track the provider is by storing it in the backend session state and generate a reference to that session/state that you pass in the state parameter. To prevent cross-site request forgery you should also keep some encrypted/randomized cookie that binds the state to the browser. This is described in more detail: https://www.rfc-editor.org/rfc/rfc6749#section-10.12
Addendum:
One of the problems with using OAuth 2.0 + provider specific extensions for login is exactly this: you cannot establish the provider and user identity in a way that works for all providers in a uniform and generic way. In your case you'll already have to know the provider before you can perform a sensible interaction with it. Enter OpenID Connect: it is a extension profile of OAuth 2.0 that gives you login semantics in a standardized way. It would give you a verifiable JSON object (JWT) with standardized values that tell you who the provider is (iss) and who the user is (sub).
Google signin already has migrated already to OpenID Connect, as has Microsoft and others like Salesforce, hopefully Facebook will follow.

Transparent user registration after external authentication in Drupal

I'm working on a Drupal 6 module to provide OAuth-based user authentication and registration. I'm already using the OAuth module to authenticate as described on http://oauth.net/core/1.0a/#anchor9. The next step is to create the user account using information provided after authentication using an custom API of the Service Provider.
According to http://drupal.org/node/497612#comment-3047302, I should not use user_external_login_register() but see the OpenID module for how to properly login an external user.
After studying the OpenID module, here is what I plan to do:
Try to load an existing user for a authname build from the custom API result using user_external_load().
If a user exists, use user_external_login() to log the user in.
If not, pretend the registration form has been submitted (like openid_authentication() does) to create a new user account. And redirect to a pre-filled form if any additional information is needed in order for the user to register.
Is this the right way to do it ? Is there another module worth looking at for how to this properly in addition to OpenID ?
You could have a look at the former Drupal module. That module did two entirely different things (hooray for the architecture :)).
* It puplished information to a central "who runs Drupal" directory. (and offered a page to show such a directory yourself!)
* It allowed login with credentials from other Drupal-sites.
The latter is what you are looking for. Note that the module was discontinued, not because the method for logging in was done wrong, but because the DrupalID mechanism itself is flawed. It has been replaced with openID and oauth.
http://drupalcode.org/viewvc/drupal/drupal/modules/drupal/drupal.module?hideattic=0&view=markup
The hooks and methods you would be looking for (in that order) are:
drupal_form_alter -- Adds validate-callback to the login forms.
drupal_form_user_login_alter -- Adds information about alternative login on login form.
drupal_distributed_validate -- Validation callback: calls drupal_auth to see if the user is valid. If so, calls user_external_login_register
drupal_auth -- Helper for validation callback: determines if the credentials are valid.
All other functions are either helper functions for these, or provide that directory-feature, or allow remote sites to authenticate against our database. Neither of which you will be using.

Resources