cancel
Showing results for 
Search instead for 
Did you mean: 

User authentication via XSUAA in Kyma Environment

francbele
Explorer
0 Kudos

Hello,

I am using Kyma Environment momentarily only in my Trial Account so I can test it's features and implementations.

I deployed a dummy app so far. I would like to access this app only by authenticating an user via XSUAA but I really can't find a good example on how to do that. I have created an Authorization & Trust Management Instance (XSUAA) and I can successfully create a binding between the app and the XSUAA instance.

If I test the binding with the Postman using the bindings client id and client secret I can successfully "log in" and get the token, but later on I don't know how to "protect" my app so it won't be directly accesible without an authentication. So the binding is there, sucessfully created and working, but the app is still publicly available. Are there any settings to be made in "API Rules" segment? If I use "Allow" or "noop" my app is always accessible. What configuration should I make to achieve this?

Thanks for any help in advance.

View Entire Topic
jamie_cawley
Advisor
Advisor
0 Kudos

Hi Franc,

For user based authentication an apirule will only validate a jwt, it will not issue them. For user based authentication/authorization you can find an example at

https://github.com/SAP-samples/kyma-runtime-extension-samples/tree/master/app-auth-proxy

This app will be exposed to the internet and configured with xsuaa to authenticate/authorize users. After this takes place it will proxy a connection to the k8s service of you app, so there is no need to expose your app via an apirule. The example is currently setup to work with some of the other examples in the repo, so you would need to modify the configmap to work with your app. If you have any questions please ping me on https://messages.sap.com/

Regards,

Jamie

francbele
Explorer

Hi Jamie,

Thank you for the swift reply!

I have seen this example before and I thought that it's being used in some other scenarios. I'll definitely give it a try!

Kind Regards,

Franc

francbele
Explorer
0 Kudos

Hi Jamie,

I managed to make your example to work. Thank you!

Can I use Approuter User API Service with this solution in order to get user information? Is it going to work?

Thank you.

Kind regards,
Franc

francbele
Explorer
0 Kudos

Hi Jamie,

One more thing that I've noticed is that since the solution doesn't seem to work with Postman.

I use the secret generated by the Credentials of app-auth-proxy (in your example), then I use Grant type Password and my user details. The scope remains blank or it's set to "openid" as it is always "openid". I successfully get back the generated token, but then when I make the request using this generated token I always get a response as HTML which is the Login site of the XSUAA.

Do you know how to access the resources using the OAuth Access Token?

Thank you.

Kind regards,
Franc

jamie_cawley
Advisor
Advisor
0 Kudos

The app has two endpoint to get user info /auth/user and /auth/groups. I am not so sure that postman supports open id connect authentication.

Regards,

Jamie

cupertino
Discoverer
0 Kudos

Hi jamie.cawley ,

is there any way to control access to the target service / endpoint through the app-auth-proxy?

At the moment any user of my kyma cluster seem to be authorized when using routes.http_method_scopes.scope: "*" within config.json

Playing around with the scope value is not really working. "$XSAPPNAME.runtimeNamespaceAdmin" for example leads to "Unauthorized." response despite the fact that my user (i.e. Email) is actually set as namespace admin.

Am I missing something?

Edit: Is it possible to set up custom role-collections, role-templates and scopes within the xsuaa service instance configuration? If so, how must the scope value be set in config.json (configmap.yaml respectiveliy)?

Thank you.

Regards,

Josef

jamie_cawley
Advisor
Advisor
0 Kudos

The scopes would be based on the service instance created under Create XSUAA Service Instance, see the link under step 7. Kyma roles are no longer assigned within BTP, they are done within the cluster, so runtimeNamespaceAdmin would no longer be valid.

Regards,

Jamie