nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Add token based authentication to Activiti

damokles

As suggested by Daniel Meyer I'll open a discussion for the issue here.

Description

At the moment the only way to sign into the Explorer is via username/password authentication,
we suggest adding a token based authentication to that.
The basic idea is that a you can generate login tokens using the IdentityService, these can
be used e.g., to generate notification E-Mails with a direct login url, or that another
application can request such a token via the REST interface so that the user does not
have to authenticate again.

Of course certain security measures need to be implemented e.g., limited lifetime/uses of a token.

We are willing to provide the implementation if it will be included into Activiti.

Any comments?

Find more posts tagged with

Comments

meyerd

Hi damokles,

> We are willing to provide the implementation if it will be included into Activiti.

usually it works the other way around: you show what you got, we decide whether we can to include it

So we will not promise to include it before we have seen it

From what you write I gather that the code does not exist yet?
We are talking about the new Vaadin-based explorer, correct?

Here are a couple of things you can keep in mind when developing this:
- You should keep in mind that adding such features to that webapp does not have the *highest* priority for us.
- If it requires any changes in activiti-engine I think chances for it to be included are very poor.

damokles

Hi meyerd,

you are right that the code does not exist yet. Of course I understand that you cannot promise to include it beforehand
without having seen the code. What I meant is that we would not invest the time and money if there is no/only a small chance of it becoming part of activiti.

If it requires any changes in activiti-engine I think chances for it to be included are very poor.

It does not necessarily need to be included into the engine, but IMHO it would be the best place for something like this to
be handled by the IdentityService.

We are talking about the new Vaadin-based explorer, correct?

Yes, but it does not have to be limited to that, if it is implemented in the IdentityService than any other software could
use it.

You should keep in mind that adding such features to that webapp does not have the *highest* priority for us.

Thats why we would offer to implement those features.

ronald_van_kuij

If it is not something based on a standard (SAML2 being the only one coming to mind), I personally would not include it. But that would mean including something like http://forgerock.com/openam.html because you want to be realy useful.

But even then, you often run into so many limitations (not meant to be negative) for the explorer to be a real end-user application or rather to develop a full blown end-user application with it, that adding complex I&AM is way to complicated…

But that is just my €0.02

damokles

If it is not something based on a standard (SAML2 being the only one coming to mind), I personally would not include it. But that would mean including something like http://forgerock.com/openam.html because you want to be realy useful.

SAML2 is used when your service and identity provider is not the same entity, that is a totally different scenario.
We don't want to create a link to an external identity provider, we simply want to allow the user that is already
authenticated via one system (e.g. REST) to be able to use another system (e.g. Explorer) without having to use
username/password authentication again. But both systems REST, Explorer would run with the same activiti engine instance.

ronald_van_kuij

I disagree. The usecase you describe where another application can request a token so the user does not need to login again is specifically one of the functionalities for saml, regardless of whether they are in a different entity or not. Getting a token from Activiti is like being an identity provider and the webapp and rest interface are both service providers.

If you develop something that is not usable outside the Activiti realm (pun intended) it is doomed from the start. but that is from my fairly broad experience. I might miss a usecase though

The usecase of tokens in emails should not result in an option to kind of be fully authenticated in an engine I think. At most it should allow you to complete one task. We have public tasks for this tat do not require autentication and the ask is 'assigned' to a hash that is in the email.

Cheers,

Ronald

damokles

I disagree. The usecase you describe where another application can request a token so the user does not need to login again is specifically one of the functionalities for saml, regardless of whether they are in a different entity or not. Getting a token from Activiti is like being an identity provider and the webapp and rest interface are both service providers.

If you develop something that is not usable outside the Activiti realm (pun intended) it is doomed from the start. but that is from my fairly broad experience. I might miss a usecase though

The usecase of tokens in emails should not result in an option to kind of be fully authenticated in an engine I think. At most it should allow you to complete one task. We have public tasks for this tat do not require autentication and the ask is 'assigned' to a hash that is in the email.

Cheers,

Ronald

I'm no expert in SAML so maybe my understanding is wrong, but looking at the sequence diagrams 1 and 2 the user is forced to authenticate again via the web browser.

Let me describe our use-case, we have developed a small desktop widget that lists the tasks of the user, either assigned or candidate. The user can then click on a task and we redirect him to the activiti-explorer. If he was already signed in then everything is OK an he can view the task, but if not he has to enter his credentials again. We want to avoid that by adding a token to the url that the widget gets from the REST service so that the user is already authenticated with the explorer.
From what I've seen of SAML I don't think that is possible, but if it is the please tell me how.
Bear in mind that the widget is not reachable from the explorer so that a request initiated by activiti is not possible. Another thing is the problems with certificates that are required by SAML which makes it way harder to use, since you now have to manage those as well.

ronald_van_kuij

How would the widgets autenticate? If that url is protected with saml, you already have a token to use again in other calls. No difference there. So i am not sure what example I should provide…

damokles

The widgets use the REST service offered by activiti-rest and authenticate with Username/Password (HTTP Basic Auth). What I'm talking about is not the widget making other calls but the widget providing a link to a task, e.g. http://activiti/activiti-explorer/#tasks/1021?authToken=abcd that is opened with the browser and when the authtoken is valid the user would be signed in.

chearius

Hi guys,

I've been following your discussion and would like to share my opinion with you.

I think that the idea of using a standard like SAML2 and a software like OpenAM is not a bad one. But the question is, whether a) the use cases described by damokles can be solved using these technologies and b) what is the cost and the gain implementing the described use cases with those technologies.

Ad a)
You can use OpenAM (for example via the REST interface) to acquire the SSO / SAML token within the widget described by damokles or any other (web) application. After that, this token can be forwarded in URL via the web browser to activiti and verified against OpenAM. So far so good as long as the SSO session is still alive; otherwise the user need to re-authenticate.

In case of sending a link via email, this can not be easily done with OpenAM or a SSO token respectively, since there is no guarantee that the SSO session still exists after sending the email (not to mention the user's credentials would need to be used by the service sending the email in order to establish the SSO session); and the receiver may need several hours or days to use the link. So this scenario can not be realized with OpenAM / SAML.

Ad b)
Implementing the features requested by damokles using OpenAM would mean quite a bit overhead, not only because the identities need to be administered by OpenAM and not by Activiti and a mapper would have to be implemented; but also the administrative efforts would become much higher. The installation, configuration and operation of OpenAM only for this sole purpose is a overkill.

In my opinion, the easiest and most efficient way to implement the features requested by damokles would be to implement a token-generation service within activiti itself and make it accessible via the REST interface. In order to be able to easily switch to OpenAM in the future (for whatever reasons), the REST interface can be designed to be compatible with OpenAM's REST interface, even if it does cover the whole functionality.

Sincerely,
Marek Šiller

meyerd

the easiest and most efficient way to implement the features requested by damokles would be to implement a token-generation service within activiti itself

As already stated: I do not really see that happening in engine

ronald_van_kuij

Ad a)
Yes, 2 different usecases, that is why I mentioned the 'link in the email' usecase should just make it possible to finish one specific task. The other one is a real SSO usecase. The latter should be solved by a standard, the former should be solved by a 'very simple token' (indeed no SAML here) Creating a simple SHA-256 hash over some known data and e.g. a salt and assigning the task to this 'token' solves this issue. In that case you cannot use it to do anything else, just finish this task. This latter usecase can be easily done in your own code, no need for anything else and no need to add it to Activiti

Ad b) OpenAM is a full solution, which was 'a proposal', just using OpenSAML would require a lot less. Administration in our case (and external ones) never fitted in the Activiti user/group model anyway (remarkably (not!) enough the OpenAM one did since it is really targeted at I&AM), and often there are existing solutions. So we 'just' use the activity engine and no user/group management.

As Daniel stated, I do not see a kind of SSO solution being embedded in the core, including the token for email…