[
https://issues.apache.org/jira/browse/CAMEL-8404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Pocock updated CAMEL-8404:
---------------------------------
Description:
This issue is to discuss adding support for algorithms from the Initiative for
Open Authentication (OATH)
http://en.wikipedia.org/wiki/Initiative_For_Open_Authentication
These algorithms are typically used for two-factor authentication, where the
user carries a device such as a token that displays a OneTime Password (OTP) on
the screen. Soft-tokens are also available, e.g. the dynalogin app for Android
implements HOTP.
HOTP is a counter-based OTP. Each time an OTP is generated or authenticated, a
counter value is incremented on both client and server.
TOTP is time-based (the timestamp takes the place of the counter value in the
algorithm, authentication can not be performed twice in the same time interval).
There are two general approaches Camel could take:
a) component that implements everything within the JVM using a HOTP Java
library. The underlying algorithm is HMAC so this is not hard to implement,
the dynalogin app source code provides a trivial example. The component or the
route would need to have some mechanism for updating the counter value in the
user database each time a successful authentication occurs.
b) component that delegates all operations to a black-box style OATH server
like dynalogin. The route would give a token value to the dynalogin server and
receive a response confirming whether the OTP was accepted. In this case, the
dynalogin server is responsible for maintaining the counter values in the user
database.
As well as OTP authentication, OATH also provides two-way authentication and
message signing algorithms. In these cases, the same token devices and the
same shared secrets can be used. In the case of signing, the user enters some
digits into their token device (the digits may represent the amount of a
financial transaction or the account number of the payee) and the token will
generate an OTP based on those digits. The component would then verify that
the amount or payee account number match some other values in the exchange
headers.
was:
This issue is to discuss adding support for algorithms from the Initiative for
Open Authentication (OATH)
http://en.wikipedia.org/wiki/Initiative_For_Open_Authentication
These algorithms are typically used for two-factor authentication, where the
user carries a device such as a token that displays a OneTime Password (OTP) on
the screen. Soft-tokens are also available, e.g. the dynalogin app for Android
implements HOTP.
HOTP is a counter-based OTP. Each time an OTP is generated or authenticated, a
counter value is incremented on both client and server.
TOTP is time-based (the timestamp takes the place of the counter value in the
algorithm, authentication can not be performed twice in the same time interval).
There are two general approaches Camel could take:
a) component that implements everything within the JVM using a HOTP Java
library. The underlying algorithm is HMAC so this is not hard to implement,
the dynalogin app source code provides a trivial example. The component or the
route would need to have some mechanism for updating the counter value in the
user database each time a successful authentication occurs.
b) component that delegates all operations to a black-box style OATH server
like dynalogin. The route would give a token value to the dynalogin server and
receive a response confirming whether the OTP was accepted. In this case, the
dynalogin server is responsible for maintaining the counter values in the user
database.
> add an OATH (HOTP / TOTP) component
> -----------------------------------
>
> Key: CAMEL-8404
> URL: https://issues.apache.org/jira/browse/CAMEL-8404
> Project: Camel
> Issue Type: New Feature
> Affects Versions: 2.14.1
> Environment: n/a
> Reporter: Daniel Pocock
>
> This issue is to discuss adding support for algorithms from the Initiative
> for Open Authentication (OATH)
> http://en.wikipedia.org/wiki/Initiative_For_Open_Authentication
> These algorithms are typically used for two-factor authentication, where the
> user carries a device such as a token that displays a OneTime Password (OTP)
> on the screen. Soft-tokens are also available, e.g. the dynalogin app for
> Android implements HOTP.
> HOTP is a counter-based OTP. Each time an OTP is generated or authenticated,
> a counter value is incremented on both client and server.
> TOTP is time-based (the timestamp takes the place of the counter value in the
> algorithm, authentication can not be performed twice in the same time
> interval).
> There are two general approaches Camel could take:
> a) component that implements everything within the JVM using a HOTP Java
> library. The underlying algorithm is HMAC so this is not hard to implement,
> the dynalogin app source code provides a trivial example. The component or
> the route would need to have some mechanism for updating the counter value in
> the user database each time a successful authentication occurs.
> b) component that delegates all operations to a black-box style OATH server
> like dynalogin. The route would give a token value to the dynalogin server
> and receive a response confirming whether the OTP was accepted. In this
> case, the dynalogin server is responsible for maintaining the counter values
> in the user database.
> As well as OTP authentication, OATH also provides two-way authentication and
> message signing algorithms. In these cases, the same token devices and the
> same shared secrets can be used. In the case of signing, the user enters
> some digits into their token device (the digits may represent the amount of a
> financial transaction or the account number of the payee) and the token will
> generate an OTP based on those digits. The component would then verify that
> the amount or payee account number match some other values in the exchange
> headers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
