eclipse / hawkbit

Eclipse hawkBit™
https://projects.eclipse.org/projects/iot.hawkbit
Eclipse Public License 2.0
453 stars 187 forks source link

Problems configuring HawkBit user using Cognito as OIDC provider #1780

Closed matkomilovich closed 1 month ago

matkomilovich commented 1 month ago

A few days ago, I submitted another ticket reporting an error where all the rollouts I created were permanently stuck in the "creating" status (#1770). In this ticket, it was suggested that the issue might be due to the value assigned to my username returning "null," which I confirmed through local tests with my database.

After identifying the source of the problem, I suspected it could be due to the configuration of the Cognito instance I want to use to manage/authenticate users (currently, I only use one user created from Cognito). So, I tried adding standard and custom claims to the ID token, but none of them worked (I tried preferred_username, name, username, nickname, among other less likely options). I also tried adding the userInfo endpoint using spring.security.oauth2.client.provider.oidc.user-info-uri in the update-server's application.properties, but this didn’t work either. For reference, here are the OIDC authentication configurations currently documented in my application.properties:

spring.security.oauth2.client.registration.oidc.client-id=clientID
spring.security.oauth2.client.provider.oidc.issuer-uri=https://oidc-provider/issuer-uri
spring.security.oauth2.client.provider.oidc.jwk-set-uri=https://oidc-provider/jwk-set-uri

Since the OIDC configuration didn’t seem to be working, I started reviewing how the CreatedBy and LastModifiedBy values were set in the code. That's how I found the setCreatedBy() and setLastModifiedBy() functions in the AbstractJpaBaseEntity.java file. I tested setting the return value of these functions to "admin", and this effectively set the CreatedBy and LastModifiedBy attributes to that string. After creating the targets, software modules, and distribution set with this change applied, I could finally start a rollout.

Despite this "workaround" seemingly fixing the issue, as far as I know, AbstractJpaBaseEntity is a base class of the JPA lib (Persistence API), which is used to work with the database and shouldn't be modified for any reason.

Do you know if there is any undocumented configuration that I might be missing? If not, what would be the most appropriate way to modify the hawkBit sources to set my username? I would also appreciate any advice you can provide to resolve this problem.

Thanks in advance for any input/comments!

avgustinmm commented 1 month ago

Did you try with token having claim preferred_username ?

matkomilovich commented 1 month ago

hi @avgustinmm! Yes, I tried creating a new user pool with preferred_username included in the standard attributes of the ID token, but the result was the same. If it helps, these are the current claims in my ID token:

{
  "at_hash": "x",
  "sub": "x",
  "email_verified": true,
  "iss": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_XXXXXXXX",
  "cognito:username": "matko",
  "preferred_username": "matko",
  "origin_jti": "x",
  "aud": "x",
  "token_use": "id",
  "auth_time": 1721399374,
  "exp": 1721402974,
  "iat": 1721399374,
  "jti": "x",
  "email": "user@mail.com"
}
matkomilovich commented 1 month ago

hi @avgustinmm, I just wanted to let you know that I found a solution for the issue, which was indeed related to the preferred_username attribute. The only difference this time was that I tested adding it to the access token instead of the ID token.

I'm marking this issue ticket as completed.

avgustinmm commented 1 month ago

@matkomilovich, thanks for the feedback