camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Pocock (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CAMEL-8404) add an OATH (HOTP / TOTP) component
Date Wed, 25 Feb 2015 10:35:04 GMT

     [ 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)

Mime
View raw message