How to enable registrationless auth (magic-links) with keycloak - authentication

we are trying to build an application which is accessable via onetime passwords without a "user" having the need to register.
We did came accross the term magic-links sent via email, but there is only some old experimental keycloack extention for this.
Is there any way to build some auth flow like the following with keycloack?
User A is a fully registered User creating some document. This document needs some interaction with a Third Party Person (TPP) not registered.
Now User A sends an E-Mail invite to the TPP with a link to the document. When the TPP opens the link our application should ask for the email address and send a magic link or code to this email. Whith that email or magic code the user gets access to the document for the time it takes to complete the approval process. After the work of the TTP is done, the access should expire (or expire automatically after X days not used).
It does sound quite similar to what is possible with SaaS offerings like https://magic.link/ or https://www.arengu.com/ but we are using keycloack and would like to integrate it into it as well.
Does anyone have an idea how to achieve this with keycloak?

I know this is outdated, but perhaps someone else coming along may find this useful. There is a newer implementation of this feature provided here: https://github.com/p2-inc/keycloak-magic-link
We have found it usable and useful for our needs and works well in the latest version of Keycloak (18.x).

Related

Managing email templates in FusionAuth

We are integrating FusionAuth into our user account / profile system for 3 SaaS apps. We'll have about 5 roles established and the onboarding process for each such user is different.
A new user signup could be brand new, could be existing but for a new role, or could be reactivation of an account. So roughly speaking we might need to establish 3 x 5 x 2 (new and returning user) emails for account verification and then the same number of welcome emails. Each email will have specific instructional text, email subject, and links.
The ability to duplicate email templates in the FusionAuth UI would be useful but clearly this isn't a complete solution. If I create multiple tenants to support our development, testing and production releases - it would really be great to be able to maintain a master list of versioned templates and to link any one of those email template versions to any tenant and app.
If you are familiar with SendGrid - the versioned templates there are pretty nice, as is the conditional logic that can be used in the templates to reduce the total number of documents that must be maintained.
For my sanity and for the maintenance burden associated with these emails, I'd like to use only FusionAuth or only SendGrid for these account maintenance emails. Since SendGrid is the more robust email solution it might be the better choice.
What can be accomplished with FusionAuth's User Actions? Can all FusionAuth email templates can be disabled from the FusionAuthUI and API?
Adding a user from our UI will require creating (or returning) the FusionAuth user, setting the FusionAuth App registration, setting the role, then triggering the necessary email.
It could be really cool if all that can be configured as a multistep User Action that creates / updates and configures the user and then triggers the SendGrid template email.
The versioning and duplicate options for email templates are great ideas. FusionAuth does not currently support email template versioning or copy / duplicate in the UI. Can you open these as feature requests in GitHub? https://github.com/FusionAuth/fusionauth-issues/issues
We do support conditional logic within the template. There is a brief tutorial in the FusionAuth docs. https://fusionauth.io/docs/v1/tech/email-templates/email-templates
To build conditional logic you can use essentially anything that FreeMarker supports. https://freemarker.apache.org/
For example
[#if user.data.favoriteColor == "blue"]
Hi ${user.firstName}, I see you like the color blue.
[#else]
Hi ${user.firstName},
[/#if]
If you have some particular use cases or need some help building the logic in your template feel free to ask for help in the FusionAuth Slack channel or ask here.
That said - SendGrid is in the email game, they will likely have some powerful features not available in FusionAuth. If you require many power user features, I wouldn't try to dissuade you from using SendGrid. But do open feature requests so we can make our email templates as useful as possible.
What can be accomplished with FusionAuth's User Actions?
User actions are sort of free form events that will be sent using our Webhook configuration. They can only be taken on a user that already exists in FusionAuth, so it may not be the right fit for your use case. In addition to User Actions, you can enable events such as user.create, etc - so you can respond to these types of events in FusionAuth if that is helpful.
Can all FusionAuth email templates can be disabled from the FusionAuthUI and API?
Not sure what you mean - you can disable the SMTP email configuration which implicitly disables all use of email. This can be done via the System Configuration API. https://fusionauth.io/docs/v1/tech/apis/system#update-the-system-configuration See systemConfiguration.emailConfiguration.enabled. FusionAuth is an API first, so everything you can do in the API you can do through an API.
It could be really cool if all that can be configured as a multistep User Action that creates / updates and configures the user and then triggers the SendGrid template email.
User Actions will not help with this use case. However, you may be able to accomplish this in fewer API calls. If you know the user does not yet exist, you can use the Combo API (Create User + Registration) to create and register the user in one step. https://fusionauth.io/docs/v1/tech/apis/registrations#create-a-user-and-registration-combined
If you omit the roles from this request, the user will be assigned any default roles configured on the application.
If you enable Registration Verification, this will send the user an email of your choosing. This is primarily intended to verify the user intended to register for the application.
The custom workflow idea is a good one however, feel free to open an issue on GitHub. I would envision it as a work flow builder for an application.
Example:
On user registration:
1. Assign role(s): [x] user
[ ] manager
[ ] admin
2. Send email: [select box for email template]

detecting link checkers (spam filter) in incoming HTTP requests

We have a site that uses a "one-time" login process for password resets which are not initiated by the user themselves. (for instance, a password reset that is initiated by an admin or another employee) A URL is sent to the user via email which can then be used to reset their password. The URL can only be visited one time. (there's more to this for security-sake but I'll keep it simple) Recently, some users have complained that when they visit the link, it has already expired. The end result is that they can't reset their passwords using this feature. We discovered that the users in question have a spam filter or "link checker" in their environment that they do not have access to. This device visits the one-time link before the user is able to, to make sure its safe.
I'm trying to solve this issue and was wondering if there's a way I can detect these type of devices on the web server when the request is made? When the spam filter visits the link, is there something in the http request that would stand apart from a regular browser? Maybe they all use a specific custom HTTP header? Or maybe there's a regex I could use on the user agent? I haven't been able to catch one of these yet, so I'm not sure what the request looks like coming from a spam filter.
Anyone know of a way to detect spam filters of any vendor by looking at the http requests? I know it's a long shot but maybe they all use a specific header for reasons such as this?
I got approval to modify the design to remove the one-time aspect of the URL. This solves the issue and saves me the headache. Thanks for the suggestion, #PeeHaa

Security Risks of having an API for registering a new user

I have this question in mind and I wanted to get other developer's opinion on this issue.
For creating a user (like in Facebook or creating an account in Gmail), some people suggested to have an public/private (means we don't tell developers how to use it) action in API for it. I, however, think it is a security risk as even if it is not documented, a hacker can simple see the calls and http requests when our front-end app is using that api action to create a new user (using a web debugger like fiddler) and can find the url to that action so simple ! like this POST ~/api/user/create
and then he/she can send thousands of requests to create user, users needs to be verified but still he/she is adding a lot of junk users in our database and puts a lot of pressure on our servers.
So the question is how do we handle this? Allow this only on our website or what?
Thanks
You can use CAPTCHA to verify that's a real user.

Using REST to Login user to Windows Live

I was reading through the windows live developers doc here. In that I saw they are having an authentication method something like this.
GET https://oauth.live.com/authorize?client_id=CLIENT_ID&scope=SCOPES&
response_type=RESPONSE_TYPE&redirect_uri=REDIRECT_URL
I understood everything except for where do I give the username and password of the user?
I am planning to create an app(first one in my life) to learn the working.
I also have never used or coded something over REST.
When using OAuth, your application never receives the user's username or password. Rather, the user logs in to Windows Live on the Windows Live servers and authorizes your application for access to their information. After they have authorized your application, you receive an access token from Windows Live on behalf of the user. You then use that access token with the Live API to retrieve user information.
Coding something using REST protocols isn't anything too terribly complicated. It has been my experience that you're just specifying parameters to the API using GET or POST as your request method. Adding OAuth on to your requests is a matter of specifying additional parameters.
You're task is to learn two things here since you've never done REST or OAUTH before. Spend time looking at both.
Oauth is hard to get and hard to implement.
You should choose an off-the-shelf Oauth library they exists for most languages.
(Then you do not have to worry about the details. OTOH: You should know how it works to know how to set up and fix if something goes wrong.)
http://oauth.net/code/

Using the same credentials to login to two Joomla! sites (1.5 & 1.6)

I am looking for a way for my users to be able to login to both of my Joomla sites (one running 1.5 and the other 1.6) using the same credentials. For example, if a user registers to my Joomla1.5 portal, when they use that same info for my Joomla1.6, they get logged in without having to re-register and vice versa.
I guess an authentication plugin would be the best solution in combination with a XML-RPC service? Joomla1.5 site's plugin is triggered which "communicates" with the Joomla1.6 site where the user is already registered, if the credentials check out, a new user is created and the user automatically gets logged in.
Thanks in advance for any ideas/help.
You are trying to do two very different things that will require two very different plugins. First, you need a bridge to handle user table synchronization. You not only have to create a user for each site, you have to sync everything about both accounts each time anything changes. This would include changing email address, password, or even user name plus any other related data such as the use groups that the user belongs to. A good place to start would be jFusion, which is designed to bridge Joomla with other software packages but can certainly be modified to bridge Joomla sites. JFusion also has the added advantage of creating user sessions for each connected software package for a single unified login, which would be the second piece of the puzzle you would need to solve once you get the users sorted out.
http://www.jfusion.org/