I am using WSO2 IS 6.0. Is there a minimum client ID length required to set a client ID in OAuth/OpenID Connect Configuration? If there is any default length, how do I change it?
Thanks
There is no defined minimum length for client ID.
When you are creating the application through REST API you can define the client ID (even if you input a single character as the client id, it will be considered). So, if the application developer/admin defines the client id be mindful to add an unguessable id.
If the client id is empty, a random id will be generated by the server. Refer to the code base. That generated client ID has a length of 28 characters. There is no config to change the default length for the generated client id.
Related
In my WSO2 Identy Server (v5.8.0), i have added one custom attribute named XXX.
Then, in my web client application, I invoke /scim2/Users service to create new user inside IDS.
I successfully create user with correct name, surname, email, phone number and so on, but my custom field is not updated in my user content store.
By other hand, if I update field by data entry and read my user from IDS, I can see my custom attribute XXX correctly.
Can someone help me ?
One of the following reasons could be caused not to update custom attributes via scim2/Users endpoint.
Once you add a new local claim and if you want to access/modify its value using SCIM endpoint it should be mapped to scim claim dialect. Follow the steps in extending scim user claims doc in https://docs.wso2.com/display/IS580/Extending+SCIM+2.0+User+Schemas
If the above step is correctly configured, check the request payload whether the attribute is correctly defined in the payload. If the attribute is not defined in the expected format, WSO2 IS ignores those attributes.
When you trying to update the value via login to the management console and view the user profile through the management console doesn't involve the SCIM APIs. You are directly updating the local claim in the WSO2 local claim dialect. If you have followed the doc mention is step 1 and that attribute has a value, GET /scim2/Users/{user-id} should return the attribute in the response.
Is it possible in WSO2 Identity Server self-registration process to request only the First and Last name of a User and generate a username instead of asking the user to enter the desired username?
The default WSO2 identity server self-registration process does not allow generating username by the given first and last name.
But according to the wso2 documentation of Customizing WSO2 Identity Server UIs, you can customize the WSO2 Identity Server self-registration process to request the First and Last name to generate a username by concatenating the first and last name accordingly.
The generated username should be unique and obey the defined username regex in the user store. In the documentation of Working with Properties of User Stores, you can find the user store properties related to username regex. Therefore you should verify that the concatenation of first and last name, generates a unique username that complies with the username regex.
I want to build an in-app chat application without any login.
So, the user communicates with the program (the backend), not with other user. So, it's a chatbot.
My question is: How to identify the user? Should I just log the IP address? Or, should I generate a random ID on server? Or, should I just generate it on the client?
As I understand, the purpose of identifying the user is for the server to keep track of who is sending the chat message and to send back the response to the appropriate client (user). IP address can't be reliably used as a way of uniquely identifying the user because of numerous reasons (it is a separate topic). One example of it would be this - A small company routes all the outgoing traffic from its office network via a single router that has a single IP address. In this case, the requests coming from different employees of that company would have same IP address as detected by the chat server. So it can't distinguish between these users.
The idea of generating unique identifier on the server for each user can work. A UUID or a JWT or something similar can be used to generate the id when the user initiates the chat for the very first time. This ID needs to be passed back to the client so that clients (users) can send the subsequent chat messages using the same ID. Thus, in this model, the client would need to have a place to store this ID so that it can keep passing it back to the server in its chat messages. Now the problem can happen when the client loses this ID. How can we recover from this situation? The answer would be similar to the approaches being used when someone loses their password. There are several recovery mechanisms such as sending the reset link on the trusted email address or sending it on user's phone as a code or generating a recovery key which is different from the ID and emailing it out to the user which can later be used to reset the ID. Basically, there should be an alternate and secure way (recovery flow) to identify the user if the ID is lost.
If the ID is generated on the client side, that can also work as long as all the clients are able to generate the ID that is guaranteed to be unique. Clients can pass in the generated ID to the server and server can check if it is already used and send a retry message to the client if it finds that it is already used. Or if the clients are using some hardware that has unique serial number and that serial number can be used to generate the ID.
In either cases, all the requests must pass in the ID to the server so that server can do the identification.
Hope this helps!
Is it possible to use userID and the API to record a user having done an event (i.e. reached a goal) by API?
For example, if I set up my GA installation to record userID for logged in users, but the Goal I want to record is something that happens when the user is offline.
Can I use an API somehow to tell Google "User 001 completed Goal X"?
Or, alternatively, can I pull a unique identifier from a user's cookie, store it on my server side linked to the user id, and fake a js call back to Google once the goal is reached, as if the user were viewing a success page?
You can fetch the client id from the cookie. Google recommends to use their get function:
ga(function(tracker) {
var clientId = tracker.get('clientId');
});
as
developers should not directly access the cookie analytics.js sets as
the cookie format might change without warning.
You can then send an event or virtual url using the measurement protocol and set up a goal based on that url or event (btw. there is nothing "fake" about it, this is exactly the thing the measurement protocol is supposed to cover).
The caveat is that the data will probably end up in a new session, so the original source might get lost (that's an issue if you do advertising).
Another approach, if your users are usually logged in, would be the User-ID feature (despite it's name it does not ID individual users, but it allows to collect user data across devices as long as an unique ID is sent per user from each device. The Id is not exposed in the interface).
You would again use the measurement protocol but this time send along the user id (you still need to send a client id, but it will be overwritten by the user id). If you enable session unification the logged-in visits of the users (and your measurement protocol calls) will be stitched together into a user-level reporting (this required a special data view which will include only data from visits that have a User Id set). Unlike the client id, which is generated by the Google Analytics Javascript code, the User ID is generated on your server and passed in to GA.
So I am working on a mobile app right now that will be making requests to a REST API built with Django.
In order to secure the API I plan on using a private/public key pair authentication system.
The workflow I have thought out goes something like this:
The user logs in using Facebook
Once the user signs the app generates a private key
The private key is shared between the server and the app so that the server knows to map that private key to a specific user.
Every time the mobile app makes a request the app generates an HMAC/signature using the request parameters and the private key. In addition to the HMAC the app also sends the user_id of the user who sent it (this will act as the public key).
When the server receives the request it generates its own HMAC. Its takes the user_id and looks up the private key in a table. Using the private key it recreates the HMAC with the request parameters and compares it to the HMAC that the mobile app sent. If the server and the mobile have matching HMACs then it performs the request.
Now my problem lies in step 3 where the private key has to somehow be shared between the mobile app and the server. How can I securely send the private key?
I would start by asking why the server part of your app needs to know the private key. If it only wants to authenticate a user, it only needs the public key and the user id, and the user id cannot iself be the public key (you need a way to find out which public key to use).
For instance, the process of sharing the key, your step three, could look something like this:
The app generates a public-private key pair.
The app sends the public key to the server, not caring who can intercept it.
The server stores that public key, associating it with the id the user provided.
Maybe the integration into Facebook is the part that makes this impossible. I do not quite understand how Facebook comes into this whole process.
One thing that can make the transfer of a key slightly more secure is to use multiple channels to transfer it.
For instance, your application could send the private key that was generated using your REST API but encrypting it with a symmetric encryption scheme. The symmetric encryption key can be sent via some other medium, such as email, or through SMS since this is a mobile app, or maybe even an automated phone call placed to a number provided by the registering user. The key can be a random passphrase that generates the actual symmetric encryption key, to make sure it is something that can be typed in by the user. Then, to unlock the app, the user needs to type in this passphrase into a screen and the secret key is unlocked.
Again, this only improves the security of the transfer by a small margin, especially considering the fact that if you can intercept the transmission of the private key, you can probably intercept the email containing the passphrase. In my opinion, not sending the private key to the server would not only be optimal but required.