How to set up a single Spartacus application to run several different web stores against a single BA Hybris (several Base Stores).
We need to ensure that the user sessions are not mixing.
What would be the configuration for the Spartacus and what are the eventual implications.
What should be done on the BA side.
Thank you in advance.
Spartacus can automatically detect existing sites with requesting below URL: https://backend.site/occ/v2/basesites?fields=baseSites(uid,defaultLanguage(isocode),urlEncodingAttributes,urlPatterns,stores(currencies(isocode),defaultCurrency(isocode),languages(isocode),defaultLanguage(isocode)),theme,defaultPreviewCatalogId,defaultPreviewCategoryCode,defaultPreviewProductCode)&lang=en&curr=USD
Spartacus will match current URL with existing website URLs on backaoffice. Check spartacus documentation for details.
You need custom implementation for prevent mixing user sessions. Because spartacus using OAuth2 protocol. You can use UserFilter or others for checking it.
You didn't share your customization so I can't say about your BE works.
If you haven't got any customization, you just need to implement filter for checking user tokens for preventing mixing sites in BE side.
Related
I have a web application which runs until now with cloud run, but without access restriction. Now it should be available only for certain users.
I read https://cloud.google.com/run/docs/authenticating/end-users and also tried both
mentioned ways: Google-Sign-In and the "Identity Platform" tutorial.
If I understand correctly, you have to program the actual user handling yourself in both variants. For example, determining which email addresses have access to the application, etc.
I was looking for a declarative way where, ideally, I only maintain a list of permitted email addresses and the "cloud run application" is only "magically" linked to this. With the result that only these users get access to the web application. That doesn't seem possible?
Ideally, the actual application should not be changed at all and an upstream layer would take care of the authentication and authorization, possibly in conjunction with the "Identiy Platform".
Best regards and any hint is welcome
Thomas
Let me add some sugar to this to better understand all these.
A Cloud Run application is packaged by you, you maintain the source code, if this is a website, placing a login button and handling authentication is your job to accomplish.
A Cloud Run system which is running all this on a hardware, it doesn't "look into" or handles your application code outside of the "code". Simply put it doesn't know if it's a Java or Python code and how to handle authentication out of the box for you - but read further.
If you require a simple way to authorize look into API Gateway it can be placed "before" Cloud Run. It might not be exactly your use case. These exists only for "API" designed services.
That upstream layer you need is the managed Identity platform, but the CODE should be assembled by you and deployed inside your Cloud Run service. The code will be the UI driven part, the authorization logic is handled by the Identity Platform so it reduces the amount of development time.
Your users would sign up using a dedicated registration page, and sign in by entering their emails and passwords. Identity Platform offers a pre-built authentication UI you can use for these pages, or you can build your own. You might also want to support additional sign-in methods, such as social providers (like Facebook or Google), phone numbers, OIDC, or SAML.
Look into some of the advanced examples to get a feeling how authorization can be customized further: Only allowing registration from a specific domain you could reuse one of these samples to maintain that shortlist of users that you mentioned.
In addition to #Pentium10's answer, you can also make all users authenticate to your app somewhat forcibly. (Imagine you're building an internal portal for your company, or an /admin panel for your app that only certain users/groups can access.)
This sort of use case can be achieved by placing Cloud Identity-Aware Proxy (IAP) in front of your Cloud Run service. That way, all requests go through this proxy that validates the caller. This is not like Identity Platform in the sense that visitors don't create accounts on your website (they use existing Google accounts or other IdPs like ActiveDirectory, or whatever you configure on IAP).
I have a little tutorial at https://github.com/ahmetb/cloud-run-iap-terraform-demo/ since IAP+Cloud Run integration is still not GA and therefore not fully documented.
I'm currently working on a project where we are using OpenID Connect and Oauth2 with Keycloak's default forms.
We have requirements to implement 2FA. In an ideal world we'd scrap the keycloak forms all together and just use keycloak as a headless API and build the login forms in the main application itself.
The reasons being
We have components built in Vue.js we would like to re-use (e.g. password/code inputs, password strength indicator etc)
We don't want to maintain the same styles in two different projects
We don't want to maintain or be limited by custom templates
Don't want to write custom behaviour in vanilla js
After doing research I've found that using keycloak as an API is not recommended because the redirection between the client and 3rd party login acts as an additional layer of security, and is part of the OAuth2.0 model. We're storing users medical information so security is a concern.
What would you guys suggest?
You are right that using an OAuth server through an API is not recommended. Redirects are an important part of the security of an OAuth flow. This of course creates all the drawbacks that you mentioned - having to maintain multiple codebases with the same functionality.
A solution to this problem is to use hypermedia API with strong security mechanisms, which can be used to perform OAuth flows. Unfortunately this is not a standard yet, and it is an emerging feature. You can read how such an API works here and here you can find an in-depth description of the security features of an implementation we did at Curity.
It will definitely not be an easy task to implement it in Keycloak currently, but there most probably there is no other option to solve this problem - as you said you need 2FA, without 2FA an option is to use the Resource Owner Password Flow.
I want to build a REST API on a server. Say api.xyz.com, which will contain a jwt based user authentication system. I want to build different clients. Say one for android and one for a web app. How do I prevent other people to use my routes in their clients ? Is there any way ? Should I change my design principle to achieve this ?
You can do that by sharing an authentication cookie between the main domain and the API sub domain if it concerns a web site.
A common way to solve this problem when it comes to apps, is using an token based authenication system, like OAuth, which is currently at version 2.
I am in the early stages of planning (in particular for the security) of a REST API through which a mobile application authenticates and then sends data to be stored in (and also to be retrieved from) the Joomla website/database. It's basically an application-to-application authentication.
I plan to use the API for own internal use which means that the otherwise important aspect of "making it easy for third party developers/API users" is not as important. My main concern is that I of course want to prevent that illicit information can be injected through such API calls. At some stage I might also be asked by external auditors about how this security aspect is properly covered - hence I better be prepared from the start... ;)
SSL is planned to be used for client/server communication and the API will also use a username/pw for authentication, But does anyone have an opinion about (and maybe experience with) using OAuth as a security layer? I do not mean using user's social media pw for the Joomla login, I mean implementing oAuth on the Joomla Component side (i.e. the Joomla side REST API).
Thanks
This is exactly what we have done at our organization. It would have been nice to follow some existing OAuth (I assume OAuth 2) implementation using Joomla but I don't think it exists other than vanilla php implementation. We used this active project but built our own from scratch. This project takes into account all Grants and I suspect if you are doing mobile app authentication like us you will stick to the Resource Owner Password Credentials Grant. So it really depends on what you are doing.
So the first part was authenticating with Joomla from our mobile app. Here is a post on the start of that. With that we followed the spec RF6749 to follow the convention needed and produced the proper Bearer Token etc.
Then it was a simple matter of doing what was needed for the mobile apps with the REST APIs.
I'm over simplifying it (especially since I'm recommending going through the RFC carefully) but once you know how to authenticate with Joomla, your sailing. IMO.
Basically we are trying to implement CAS as an SSO solution in our org. All our user profiles are stored in a custom userstore that exposes certain REST APIs for fetching this info. What I want to know is whether I can use CAS here? Basically instead of querying a DB or an LDAP server CAS would just query this custom userstore via REST. Does CAS provide such a functionality?
You certainly can. CAS by default does not provide this functionality. However, you can leverage the existing API to design & develop a custom authN handler that talks to the custom store through the REST API.
See the deployerConfigContext.xml file to review how authN handlers are defined and placed.
Also, if you do design the custom handler, please try and contribute that back to the community/codebase through a pull request on Github and discuss the details on either #cas-dev or #cas-user. There could be a possibility of merging the changes to the codebase to accommodate future similar requests.