Hi Stefan,

does this error occur in the client once you initiate your first request?

I just tried to reproduce it and it works with one modification of your 
existing code (assuming you're using v0.69.0-SNAPSHOT for the client library 
and the core).

CredentialsProvider credentials = StreamPipesCredentials.withApiKey(email, 
apiKey);

Some background:
There are now two ways to authenticate to StreamPipes using the client. The 
first way is the API key, which is bound to a user, inherits all access rights 
the user has and can be created over the profile section. The second is a 
token-based authentication for authenticating service accounts that have been 
created in the security section of the configuration view. Service accounts can 
have individual access rights and can never access StreamPipes over the UI. We 
use service accounts e.g., to authenticate to the StreamPipes API from an 
extensions service (e.g., the data lake sink which register the schema in the 
core). To authenticate against StreamPipes with a service account, you can use 
StreamPipesCredentials.withServiceToken(). Internally, API key authentication 
works by providing two HTTP headers X-API-USER and X-API-KEY, while the service 
account authentication uses a Bearer token.

In case you're using the client within the StreamPipes network where you have 
access to Consul, you can now also discover an available API service 
dynamically without providing the URL explicitly, e.g., we use this to provide 
a pre-configured StreamPipes client instance in the wrapper [2].

I've started to write some documentation for security features, but it's still 
incomplete [2].

Please tell me if you still get an error with this change, there might still be 
bugs, so thanks for your feedback!

Dominik


[1] 
https://github.com/apache/incubator-streampipes/blob/dev/streampipes-service-extensions-base/src/main/java/org/apache/streampipes/service/extensions/base/client/StreamPipesClientResolver.java
[2] https://streampipes.apache.org/docs/docs/next/deploy-security.html




-----Original Message-----
From: Dominik Riemer <[email protected]> 
Sent: Wednesday, November 24, 2021 8:00 AM
To: [email protected]
Subject: Re: AW: User and Access Rights Management

Hi Stefan,

it is not intended to be deprecated ;-)
I'll have a look at this which seems to be a bug, thanks for the hint!

Dominik

On 2021/11/23 09:50:05 "Obermeier. Stefan" wrote:
> Hi Dominik,
> 
> thank you very much for this nice Features!!
> Is it possible that the "API Kyes" generation in the UI is not deprecated?
> I used one of this keys with the REST-API and get an 401 with the log 
> message " o.a.s.b.UnauthorizedRequestEntryPoint - Unauthorized request - Full 
> authentication is required to access this resource "
> 
> BR,
> Stefan
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Dominik Riemer <[email protected]>
> Gesendet: Dienstag, 9. November 2021 16:52
> An: [email protected]
> Betreff: User and Access Rights Management
> 
> Hi,
> 
> during the last weeks, I've worked on improved user management features for 
> StreamPipes which are now ready to be merged into dev.
> 
> Here's a summary of the changes, which I'm also currently adding to 
> the
> docs:
> * The setup page is now obsolete - at initial startup, StreamPipes performs 
> the installation in the background and adds a default user (User:
> [email protected], PW: admin). The default user can be 
> overridden by providing
> * StreamPipes can be configured to allow self-registration and to allow users 
> to restore their password.
> * StreamPipes can be configured to send emails (e.g., by pipeline 
> elements through the API or client and by the system itself for 
> password recovery or
> registration)
> * Users and groups can be managed and roles/privileges can be assigned 
> to them
> * Individual permissions can be added for pipelines, dashboards, adapters and 
> pipeline elements. Permissions can be changed by admins and are available in 
> the overview section of each resource (e.g., pipeline overview and dashboard 
> overview).
> * All requests from extensions service to the core are now authorized and 
> made over the StreamPipes client. The runtimeContext of the wrappers includes 
> a reference to the client pre-configured with default credentials.
> * The UI-core communication now relies on a standard token-based JWT 
> authentication.
> 
> I'll now merge this into dev and we'll fix some bugs in the upcoming weeks.
> It would be great if some of you can have a look and provide feedback. Some 
> things might not yet fully work, but they hopefully bring us closer to a 
> production-grade release 1.0.
> I'll also work on improving the documentation in the next weeks, so that we 
> have a well-documented version for the upcoming release!
> 
> Dominik
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
> Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael 
> Kleeberg, Axel Otto, Dr. Martin Kuntz, Matthias Feßenbecker
> Edisonstr. 1
> D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the 
> SEEBURGER Supervisory Board:
> Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
> Fax: 07252 / 96 - 2222
> Internet: http://www.seeburger.de               Registergericht/Commercial 
> Register:
> e-mail: [email protected]               HRB 240708 Mannheim
> 
> 
> Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und 
> kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material 
> enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die 
> des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der 
> SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail 
> irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, 
> Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder 
> die SEEBURGER AG noch der Absender (Obermeier. Stefan) übernehmen die Haftung 
> für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf 
> Viren zu prüfen.
> 
> 
> This email is intended only for the recipient(s) to whom it is addressed. 
> This email may contain confidential material that may be protected by 
> professional secrecy. Any fact or opinion contained, or expression of the 
> material herein, does not necessarily reflect that of SEEBURGER AG. If you 
> are not the addressee or if you have received this email in error, any use, 
> publication or distribution including forwarding, copying or printing is 
> strictly prohibited. Neither SEEBURGER AG, nor the sender (Obermeier. Stefan) 
> accept liability for viruses; it is your responsibility to check this email 
> and its attachments for viruses.
> 
> 

Reply via email to