I need integrate Liferay (version 6.2) with another service which stores information about users. Communication with service occurs through SOAP.
Is it possible use users from service to authenticate to Liferay?
Liferay integrates with external systems through LDAP already. If you use that interface, you're set. If you need a proprietary API to access user information, you will have some work in front of you.
It might be worth examining the SSO implementation and intercept newly authenticated users on this level: With the user's identity, create or update a Liferay user account on the fly through LIferay's API. To me this looks like the most promising approach from an effort/maintenance point of view, with the little information I have about your situation.
Alternatively you could batch-update all (Liferay-) user accounts from time to time, based on updates in your external system.
Let me see if I understand what need:
1- Step 1: User prompted with A login page.
2- Step 2: The credentials entered by the user are checked against a web service (could be any service)
3- Step 3: The user is either logged in or an auth error displayed to the user.
If that's what you need, then create an autologin hook. The code that call the webs service shall live in the autologin hook.
May seem intimidating, but it is trivial: likely liferay comes with a bunch of them: (take one of them as a template)
auto.login.hooks=com.liferay.portal.security.auth.CASAutoLogin,com.liferay.portal.security.auth.FacebookAutoLogin,com.liferay.portal.security.auth.NtlmAutoLogin,com.liferay.portal.security.auth.OpenIdAutoLogin,com.liferay.portal.security.auth.OpenSSOAutoLogin,com.liferay.portal.security.auth.RememberMeAutoLogin,com.liferay.portal.security.auth.SiteMinderAutoLogin
Related
I am learning SSO, so familiar with basic concepts.
I have a web application(Ruby on rails), where users are saved in Postgre DB (in AWS).
The users want to log in to another service(Rollbar) using the same user credential that they use in our application. In other words, I want to move the application's user information to an identity provider, so that the users can log in with the same credentials to the application and Rollbar using SSO.
One option I thought of is to move the users to Google workspace or Azure AD, but that is too much as I am not looking for any additional features
I did see services like Auth0 and Okta - just wondering whether I am going in the right direction
Any service name or links to documentation is appreciated
Here is my scenario. Imagine there is a Yoga studio that uses a professional booking and reservation system that exposes an API. Through this API an application can make a reservation for a client. The API takes the client's userid and password to make the reservation. The booking API doesn't use OAuth or any social media sign-ins.
My desire is to create an Assistant Action that would retrieve the list of classes and allow the client to make a booking.
My puzzle is what design/architecture to look towards to supply the userid/password pair required by the booking API.
How have others solved this puzzle?
Should I store the userid/password as "user state" associated with the action?
First, you should have a conversation with the API provider about why they don't provide an OAuth-based solution. This is a security vulnerability waiting to happen, if it hasn't already.
Second, you need to think very carefully about your own risk profile in this case:
Google does not allow you to collect credential information (ie - passwords) through your Action.
Because of this, you must use Account Linking to authenticate them.
This means that you will need something (ie - a database or data store) to manage their account on your side.
This database would be a good place to keep the username/password you need to use for them for the API...
...but it now means that you need to take extreme care about protecting this database.
You don't really say how this API allows for accounts to be created and managed. If these accounts are just used for you (ie - the user doesn't necessarily see them), then you can mitigate some of that risk by treating the username/password as an opaque token that you manage and generate and that the user never sees.
If this is something that the user is aware of, then you'll need to approach the account linking in one of two ways:
Have them log into your service via an app or webapp using this credential info that you will need to save (ack!) and then link to the Assistant using OAuth.
Have them log into your service via an app or webapp using Google Sign-In, which will carry over to your Action. Then have them provide the credential info for the API, which you will need to save (ack!).
I'm just starting a new project. The result will be an API server and a progressive web app. The API server is implemented with TypeScript and the NestJS framework, the client with Angular 6.
I've been flirting with keycloak for some time. Still, I'm not quite sure it's right for me yet. But I don't want to worry about things like token renewal anymore and find it sexy that Keycloak tells me how to create user roles.
What bothers me, is the following - integration. For my use case it is necessary that the login and all features like password reset and so on are part of my application. That means I want to create forms myself in order to be able to do this perfectly in my own design and not have a second translation process, etc. Keycloak themes are not an option. So is it possible to hide keycloak in such a way, or is it so complex that I shouldn't use Keyloak in the first place? Afaik there is already an issue with password resets - I can't request it from the user side but have to make an REST call to the admin endpoint - which is okay but not ideal since it requires me to do more server side logic ( and that is not why I want to use Keycloak).
In addition, Keycloak is too much about the GUI - which makes it difficult for me, especially during development. Because I also want to provide my team with a local instance of keycloak during development. But what is the concept to import the initial data into realms, apps and also users into Keycloak? I found some JSON imports - but so far only for realms and apps. Is there also a function to import a whole dumb?
So that my team builds on a pre-built setup and has a user for each role. A reproducible setup with Vagrant or Docker which contains the import of initial data - that would be the goal.
So in short my questions:
Is it still worth the effort using Keycloak if I want to use everything via the API or should I simply use Passport and JWT?
Can I have a reproducible setup during my development that includes realms, apps, users, user roles, etc?
So, the question asked few months ago, but I also faces with that question, and I want to answer on it.
I think that you don't need Keycloak, it is fairly enough for you to use OAuth2 and JWT.
Let's justify my answer:
You have just one client - Angular application. Keycloak useful, when you have many clients (web-js, mobile platforms) and you want to create and manage them dynamically. But, I think that, in your case, you create your client once without modification in the future.
Also, Keycloak very useful, when you have a lot of integration with third part systems (Google, Fb, Twitter and etc) because Keycloak has them out-of-box. Or you need to integrate with some SAML or LDAP provider.
You may use Keycloak, if you need some Identity and User management platform, and when you have complicated user access flow.
In the end, you could consider Keycloak, if you need SSO (Single Sign On) feature. Once logged-in to Keycloak, users don't have to login again to access a different application. But, by your description, you have just one application.
Keycloak offers features such as Single-Sign-On (SSO), Identity Brokering and Social Login, User Federation, Client Adapters, an Admin Console, and an Account Management Console.
It's an out of box solution for rapid security layer development of application.You could have single common security layer for multiple application .
You can implement you security mechanism without using keycloak.
We are using PingFederate to enable SSO. It's being mapped with the LDAP directory server and our site is able to use SSO. Now we are integrating a helpdesk software application which is being hosted somewhere within our own site. We want the help desk user to be able to login using our site credentials. For that I need to add the help desk as a partner (SP) in PingFederate acting as an IdP.
How can I achieve this? A brief explanation would be helpful. Thanks in advance.
You may want to check out the Getting Started - Part 3 recording from our website. It demonstrates how the setup a connection to a typical service provider.
https://www.pingidentity.com/support/training-center/index.cfm/103-creating-a-connection?id=1011570451001
In a nutshell, you would need communicate with your partner about federation and share some information like:
Federation Standard/Protocol,
Base URL, Entity ID, Endpoints,
Binding,
SSO profile,
Attributes,
and so on.
All of the above depends on what federation server your partner is using. Once you have all the information you can quickly setup the connection to your partner within PingFederate.
I hope this helps. I've also sent you a PM.
There's lots of good information in our documentation on managing SP connections: https://support.pingidentity.com/s/document-item?bundleId=pingfederate-92&topicId=adminGuide%2FmanagingSpConnections.html
How the connection is made largely depends on how you authenticate users, what attributes you're sending, and what the SAML capabilities/details are of your help desk software. If no SAML features are available, you may have to use one of our Integrations to either front end it (with a web server plugin, like Apache or IIS) or modify the app (using one of our language kits or agentless integration approach).
You may also want to consider sitting in one of our training sessions on PingFederate basics: https://www.pingidentity.com/en/resources/training.html
Should all else fail, our support centre is there to help if you have a valid contract.
A customer of ours has just purchased CQ5 and would like to externalize all of its security. We'd like to use an STS server for SSO and then leverage a custom authorization/attribute provider instead of the CQ5 repository. Ultimately, we do not want to use LDAP in any way.
Here is how we envision this (some pieces already working):
User browses to CQ5 Dispatcher running in Apache
Apache filter redirects user to STS site where login is completed.
User is redirected back to Apache with SAML Claims.
User ID token is placed as cookie into browser. (everything is working up to here)
CQ5 captures that cookie based on the SSO configuration (working)
Problem starts here: From here, we want to call a custom authorization provider for the user's attributes, roles, groups etc...
We have tried to figure out how to do this and can't seem to find the missing link.
Do we need to create a custom login module? Do we need to create a custom principal provider? Do we somehow use the existing LDAP capability in CQ5 but have it call a custom class which leverages the external auth source?
If anyone here has any idea how to do this, their karma quotient would be full for the year if they could share it. I'm not sure if this is a basic thing you do with JAAS or even where to put my classes after I've created them.
We've worked really hard on this so far and seem to be close, but we keep hitting dead-ends.
Thanks so much if you have an idea where to begin!!
-joe
Recent versions of AEM now include the SAMLAuthenticationHandler which allows you to:
Redirect users to SSO to simulate IDP initiated login, or
Allow AEM to perform SP initiated login with IDP
Specify attributes to take from the SAML Assertion and add to the user's profile node (not sure if you can use this for groups)
Specify which groups users should be added to
Set a cookie called request-path that will store the URL the user arrived at, and then redirect them to that location when they're authenticated (ie. deep linking)
This makes relying on the SAMLAuthenticationHandler better than using Apache to redirect. The current version of the handler bundled with AEM 6.2 does not properly set the cookie when using the redirect method, but Adobe does have an updated version that they can provide that will fix that problem.
I normally recommend that clients do not have their own authentication handlers developed inside AEM.
When not using LDAP, this does create an issue where users will not exist until they've logged in. Additionally, when your architecture includes more than one load balanced publisher, it is possible that a user may exist on one server user synchronization.
Try searching the google group for SSO details. Here's one useful post:
http://groups.google.com/group/day-communique/browse_thread/thread/72c235c83a501252/fba4d08a90487156?lnk=gst&q=SSO#fba4d08a90487156
It seems that you will have to implement a custom LoginModule, more information here: http://dev.day.com/docs/en/crx/current/deploying/custom-login-modules.html