I use my FIWARE Lab account credentials (username and password) but an empty Token is returned to me. What I see in the output is: "Token: ", so I can't get an X-Auth_Token for a specific IOTA service.
Is that a FIWARE temporary problem?
Ok, this script is obsolete. If you take a look into the Official Documentation of Orion Context Broker, you can find the corresponding scripts that you should use (token_script.sh). Keep in mind that you have to provide the corresponding project (orion-gi) apart from the user and password.
Related
I have used lifeary service builder to build my services. some of my services require that the user is authenticated before he can use them.
how can i generate an auth token and send it in the header or in the URL?
I have tried username#host.com:password#http://localhost:8080/PortletName-portlet/api/jsonws/?serviceClassName=com.service.NameServiceUtil&serviceMethodName=getMyNames&serviceParameters=[userid]&userid=1
and it did not work!
I have made sure i have added the below line in my portal-ext.properties and restarted the server.
json.service.auth.token.enabled=true
What more should i do to be able to pass Auth Token? is there a better method that i can use?
You actually want to use AuthVerifier. This is the best way how to access the Liferay API and be authenticated. It similar to the autologin concept.
Have a look at https://dev.liferay.com/es/discover/deployment/-/knowledge_base/7-0/authentication-verifiers and check out the PortalSessionAuthVerifier class in the source code.
The concept is quite simple. Read the request object and determine who the user is. Perform your custom authentication and return the auth result with the user identification.
I am creating an application in which I am getting a Client_secret.json file, and in my application I'm trying to load that json file and get the credentials from it using the following code:
credentials=get_credentials(filename)
http = credentials.authorize(httplib2.Http())
service = discovery.build('admin', 'directory_v1', http=http)
userinfo = {'primaryEmail': primaryEmail,
'name': { 'givenName':user },
'password': password
}
service.users().insert(body = userinfo).execute()
It gives the following error:
httpError 403 when requesting https
//www.googleapis.com/admin/directory/v1/users?alt=json returned
insufficient permission
I'm not sure what I'm doing wrong or am I missing something? I was wondering if the problem is in the json file which I'm creating?
Any help would be appreciated.
Thanks,
Aman
Well, you can start by checking a few things:
If you're using a service account, be sure to enable the "wide domain delegation option" to allow a service account to access user data on behalf of your users and perform operations.
Check if the scope https //www.googleapis.com/admin/directory/v1/users is authorized for your client ID on your google admin console > Security > Advanced settings > Authentication > Manage API client access.
Check if the user that you're using to insert the new user have enough privileges a.k.a super admin privileges.
Check if the Admin SDK API is active on your project.
Keep in mind that just downloading the client_json and activating a API isn't enough to allow these types of operations. For certain APIs like Admin SDK, the user you're gonna use to consume those services need to have specific privileges.
Here's a few helpful links
https://developers.google.com/identity/protocols/OAuth2ServiceAccount#delegatingauthority
https://support.google.com/a/answer/162106?hl=en
I would first check to make sure that you have the correct Admin privileges on the account that you are trying to use OAuth credentials on. I would try logging into the account and going to this reference page in the Directory API for Users:insert
https://developers.google.com/admin-sdk/directory/v1/reference/users/insert
On the right hand side you should go to the Try this API section and see if that account has permissions to create new users.
Also another thing I noticed as well, is that you're not setting the required field familyName inside of the name field. familyName is a required property.
I'm working on a project that consumes Service Now API (Rest). To do so our client has registered us as a user in order to login and make all service calls we need to. This project has an interface where users can login once they have an account on Service Now as well, the username they type to log in has nothing to do with service now by the way, but later they associate theirs service now users to it. They can do some operations through this interface, where all of them are done using the integration user/pass not their service now users theirselves, even because they do not need to share their passwords with us. But it's needed to track the correct user to register on service now and I'm in trouble specifically about commenting on an incident. The endpoint to comment is the following :
http://hostname/api/now/table/incident/{sys_id}
where request body is a json object just as simple as :
{
"comments": "My comment is foo bar"
}
but when this comment is registered on Service Now it is under integration user instead the user which commented. Is there any way I could keep a specific user, considering I already have the user id on Service Now ready to inform it on the request the way it should be.
I tried reading Service Now documentation but had no clue how to solve it, altought I've found something about impersonate
This is happening because you're being proxied through the "Integration User" instead of your own account. As long as this is the case, your comments are going to be attributed to the Integration User.
I can think of two ways to fix this issue.
Ask the client to log you into their system directly as a user.
Implement a special API (Scripted REST API, available in Geneva or later) that allows you to identify the Incident and enter the comment, and then the script forges the comment on your behalf, attributing authorship correctly.
The first solution can be expensive due to possible additional licensing costs.
The second solution will require a willing client to devote 2-3 hours of development time, depending on the programmer.
Firstly, you need an integration user with suffient rights. Our integration user has suffient rights out of the box, but your story could be different. A quick check is to try impersonate as other user using menu.
Login as integration user to ServiceNow instance.
Go to https://{instance}.service-now.com/nav_to.do
Click on username at top right corner. This is a drop down.
There should be at least three menu items: "Profile", "Impersonate User", and "Logout". If you do not have "Impersonate User" in this menu, your integration user miss some permissions. Contact system administrator if you miss this menu item to configure appropriate permissions.
Then you need to find sys_id of user that you want to impersonate. For example:
https://{instance}.service-now.com/api/now/table/sys_user?sysparm_query=user_name={username}&sysparm_fields=sys_id
If you have suffient privileges, you could invoke the folling endpoint with sys id of user that you want to impersonate:
HTTP POST to https://{instance}.service-now.com/api/now/ui/impersonate/{user_sys_id} with body "{}" and content type "application/json". You need to provide HTTP basic authentication to this query as your integration user.
The response code on success is 200. The response body could be ignored. The interesting result of this response is a set of cookies for impersonated user in response headers. These cookies could be used for subsequent REST API calls until they expire. Use some HTTP rest client dependent method to capture them and to provide them to next calls.
For Apache HTTP Client (Java), I'm creating http client context using:
HttpClientContext context = HttpClientContext.create();
context.setCookieStore(new BasicCookieStore());
Pass thing context to impersonation request and to subsequent API calls until I get 401 reply, after that I'm reaquiring cookies. Setting new cookie store is important, as otherwise some default cookies store is used.
Two things to note:
This API looks like internal one, so it could change at any time. If it happens, look for what "Impresonate User" menu item does, and repeat it youselves.
ServiceNow permissions are quite fine-grained, so the target user could lack permissions to perform operation. In some cases, if there is no permission to update the field the operation PATCH on object returns reponse 200, but field is not updated. This introduces a surprising mode of failure when you use impersonation.
I am new to setting up ping federate identity provide configuration and writing code to get token. I have got a ppt file which explain how web client connects to ping federate server and get token. and they mention to pass client_id as param but I have no idea what is client_id?
Does anyone have any idea?
client_id is your user identity. When you call writetoken() method, it has parameters to pass... hope this helps.
I will assume you are using OAuth2 or OpenIdConnect and calling PingFederate to get an Access Token.
First, here is a detailed explanation of what a client is RFC 6749 Client Registration and its role in this authentication protocol.
Second, once you understand this topic. You must configure Clients on Ping. For that you must follow their documentation Client Management.
Finally, You must point your web application to the OAuth2 endpoints passing the client_id and client_secret, with that depending on which OAuth2 flow you are using will get you closer to get an access token. You can find more information about that on Ping Documentation Site.
Hope this helped.
I'm using box API v2 and successfully with OAuth2. I'm successfully getting the access token back, but in order to avoid the "confused deputy problem" I need to have a way of getting the user id that a given access token relates to.
Is there a way of doing this? I'm trying to use the /tokens endpoint without luck. I read that you need to enable that but I can't find how. Even if I managed to enable it, would that help?
Thanks!
the /users/me endpoint will tell you the user id (and other info) associated with the access token that was used to authenticate the request. Documentation here.