We have an existing OAuth2 based website. Our plan is to use a web based (XMPP over websockets) chat system.
now this chat system will be available once the user logs in. What we actually do not want is to login twice, once for the web site and once for the chat system.
So I figured how to trick it with my own auth provider and a custom username/password.
So basically the question is how do I have an object that I want to travel along with the user chat session so that I can provide out of band processing.
Does the session management allow this?
In a similar use-case, there I need to persist and store various pieces of information about a user, in Openfire, so that external calls and look-ups are not necessary during later, custom logic in an Openfire plugin. It is possible to add any number of custom properties to an openfire user, via REST, or other APIs.
Then, those custom properties can be retrieved as needed, without external calls.
create user api
Then, if using Internal APIs, you get
Get the session's username or address (JID)
call UserManager's getUser on the username or JID to get the User object
call User's getPropertyValue to get a specific property or getProperties to retrieve all custom user properties
Related
I want to add authorization details about objects, sort of like roles associated to each object in my application as claims in my jwts. So is the right way to do this by adding calls from my issuer to the individual microservices that deal with the particular object or some other way to ensure what permissions the user has with the particular object. How would I dissociate the access token upon a change in the permissions instantly?
I have a object called namespaces that holds multiple different objects inside it, would I add API calls from the sub objects microservice to the object microservice to ensure valid permissions? But then I wouldn't be able to add it to my API gateway?
For reference I'm using
Django Rest Framework Simple JWT for login
I would also like to add token authentication to integrate with other clients but that's something I'd like to do in the future.
I have 2 applications on the same Tenant.
I can configure an email template for the "Set Password" workflow on:
an Application Level
the Tenant level
When I register a new user using the UI, as far as I understood it will only be able to send the email configured on the tenant level since it won't know anything about which application the user can see until the next step when I add the registrations.
If I create a user and add registration to it right away (on the same step) then this takes the Template configured on the application level.
My questions are:
Can we do something like this through the UI interface too? My applications have a different user base (some have accounts on both) and it would be nice to be able to send them one email or the other.
Or is this only possible through the API?
If I register a user with both applications (through the API) which email do they get?
Thanks for the help!
Can we do something like this through the UI interface too?
This is not currently possible. Creating the User, and creating a User Registration are two separate steps. As you correctly stated, when creating the user in the UI, there is no context yet for an application. For this reason, the user will receive the template configured at the tenant level.
Or is this only possible through the API?
Correct. You must use the Create "User + Registration" API to do this in one step to use the application template for setup password.
If I register a user with both applications (through the API) which email do they get?
When using the API to Create "User + Registration" you can only register for one application at a time. The email is only sent during the User Create step, so if you register for a second application, the user will already exist and thus will not receive a second email.
I'm connected to an API that provides information about cars based on their registration. According to the docs the api can provide both user specific data and general data about the registration supplied.
I am using the connection method which does require specific users data, and therefore does not require me to gain access to any specific users account.
On my end users will visit my application and enter a registration number which I will use to call the API and return all of the information about the car.
Am I right in my thinking that my application is essentially the 'user' as far as the api is concerned, and I will only need to use one access token. I can then use this access token to make multiple API calls (one for each user that searches on my application)?
Or will i need to set up an access token for each user that visits my application and treat them separately.
Only your application making the API requests requires a token, unless the licence agreement/documentation of this car API says otherwise.
As far as your users are concerned, your application is just magically sourcing the registration info from its database.
I'm looking to create a game server backend for a game I'm creating. We're currently using Firebase for handling of data and ads, and Firebase has built in authentication. Is it possible to have a user log into our app via Firebase's auth system, then confirm the user's authentication when they connect to the game server to ensure it's who they say they are?
Basically, after someone logs into our firebase, can we use that authentication information for a separate server, and what protocol/method would need to be used (if there's a specific one)
I've figured out the two steps you need to get the information required to auth, one clientside and one serverside. Note: the following examples are for the Java apis, but you can use any of firebase's equivalents.
Clientside: In the Firebase-Auth package, there's the FirebaseUser object. This contains information about their auth state, unique details, etc. There is a method here called getToken(), which will grab your token for the current authentication. Once you have this, you want to send it to the server when you need to auth.
Serverside: On the server, there's a FirebaseAuth object. Once you get the token from the client, you can use verifyIdToken(), which will confirm this is a valid token and give you the details about the user when you get the result. I suggest cross-checking the UUID against one a client sends, to just confirm someone didn't get their hands on a token and send a random ID.
Hope this helps.
I have a "chicken egg" problem.
In application I use UserDetailsService to get User (we don't store user information in our DB, we use third party service to actually get all information).
Recently we've added account activation feature. After registration, we send an activation email to a user and if he clicks on it, we mark the User as ACTIVE and redirects him to log in page. User can login only if he has ACTIVE status. The problem is: we'll start charging user from the date he activates his account even if he never logs in. How can I (maybe using spring security) make those processes (activation and login) almost simultaneous? We don't want to charge user if he just activates his account, we want to charge him only if he has logged in (after activation). So can I actually do it somehow "user clicks activation link, login and then his status is changed to ACTIVE (but he can login only if he is ACTIVE)".
Sorry if my problem description isn't clear enough
I'll appreciate any feedback.
Thanks!
If I understood your requirements correctly, you'll need two different entry points (login pages) to your application:
One for activation (first login) for users not yet activated.
Another "normal" one for active users.
The problem is that the authentication logic would need to be context sensitive and be aware of which of the above pages initated the authentication. However the framework was not designed for such uncommon use-cases, so the authentication provider has no knowledge about the URL from which the login-form were actually sent.
What you need to solve is to somehow relay contextual information to an authentication provider that processes the auth request according to that information (i.e. authenticate only non-active users logging in from url1, and authenticate only active users logging in from url2). There could be hundreds of different ways to achieve this, one possible solution is to put two different authenentication filters in place that intercept auth requests sent to the two different urls. Details outlined below:
Create your own custom versions of the existing WebAuthenticationDetailsSource and WebAuthenticationDetails (preferably by subclassing the latter) that stores and exposes the URI of the authentication request. (That will be the contextual information based on which the auth provider can implement its conditional logic.)
Configure and insert two different instances of the UsernamePasswordAuthenticationFilter in the filter chain. Set their filterProcessesUrl attribute to /j_spring_security_check_active_user and /j_spring_security_check_nonactive_user respectively, plus inject the above created custom AuthenticationDetailsSource in both of them.
Override DaoAuthenticationProvider.additionalAuthenticationChecks() in a subclass in the following way:
Retrieve the URI stored in the above created WebAuthenticationDetails object (it's accessible via authentication.getDetails())
Assert that the user is active/non-active according to the URI, and throw an AccountStatusException if the asserion fails.
Don't forget to delegate to the superclass if the assertion succeeds.
Create the two different login pages mentioned at the beginning of the post, making sure that the login forms post credentials to their respective URL (/j_spring_security_check_nonactive_user vs. /j_spring_security_check_active_user).