I am trying to get tenantId of the user with username using RemoteUserStoreManagerService service of Wso2. However I am getting Access denied error.
Unauthorized attempt to execute super tenant operation by tenant
domain - carbon.super tenant id - -1234
in the console. I have passed super tenant admin details for authorization. From the code i could see that UserStoreException is thrown where it checks for super tenant id against 0. But my super tenant id is -1234. Where am i going wrong?
As i know, getTenantIdofUser is a depreciated in WSO2 and it will not work properly. Theoretically, you can not retrieve the tenant id by providing the username. Because username is unique across tenants. There can be same username in two different tenant. As you mentioned, there is some issue in the code as well. Super tenant id must be -1234. However fixing this issue, would not provide successful response from the getTenantIdofUser as it is already depreciated.
Related
I am in the process of expanding our login options on our product to support MS Identity Platform, to be able to use Azure AD login (and gain SSO/MFA with that)
Currently we are using .Net Core + JWT (JwtBearerDefaults.AuthenticationScheme)
The environment is angular clients, .Net Core APA, and a back-end database.
I have the setup working.
My challenge is that in our business model and backend database we have ~2.000 userrights and our own User/Role model granting access.
I am currently getting the IdToken from MSAL and in my proof of concept using the oid to couple the Azure ID with our User model.
But, in our existing JWT solution, our access token holds claims about the User Id, but also the role, and another property (Unit/Vessel) determining access. From these three properties we can verify against the 2.000 userights on API side whether or not a request is allowed or not.
I would like to keep this information (User, Role, Unit) in the token - but have doubts on how.
Constraints:
We cant create/use Azure claims. We have too many, and customers will manage the Azure application - while we create, add, remove rights for each version of our software.
Azure don't know about role/unit data - and these are different for each customer - so that information can't be in Azure either.
My best idea is outlined below - would this approach be correct, and live up to the way ID/Access is separated?
I hope someone can give me some feedback on this.
My idea is, that the Angular client gets the Azure IDToken. I then use the Azure IDToken, call our API, which on server side, validates ID Token, and then grants me an access token, which contains the user, role and unit. This token is not Azure'd at all, just a token generated by our API - which again will be the only one validating it). Pro's on this approach is also I can keep one type of Access Token, no matter which IDToken is supplied by Azure or our own API.
Tried to outline the flow below in this DrawIO diagram.
I hope someone with more experience in the Token field can validate if this would be a viable approach?
Best regards
/Anders
This is a viable approach except for one thing.
Do not use Id token for authorization.
Your front-end should acquire an access token from AAD for your back-end.
This access token contains the user objectId, allowing you to map the user to a user in your database.
An Id token is only meant for the application that requested authentication and tells it metadata on the user like their display name etc., but it is not meant for authorizing anything.
I am trying to get the impersonated userguid from the docusign api. Per the documentation I need to call /restapi/v2/accounts/account_id/users?email=email, which is not working for me. I assume the full url would be https://admin.docusign.com/restapi/v2/accounts/account_id/users?email="sampleemail#gmail.com" .
I am getting a 404 when entering my email in the above format.
Looks like you have the incorrect domain. API Calls generally don't get made against admin.docusign.com. You'll want to make that call against the Application Server your account is on.
In the Sandbox environment that will be demo.docusign.net. In prod you'd need to make a UserInfo call to determine which server your account is on. It could be something like www.docusign.net or na2.docusign.net, but there are several possible domains.
In order to get Impersonate GUID ,
Login to admin account
Under setting options Click API and keys
Value under the user id text box is Impersonate GUID
During configuration & setup:
1. You have an account admin enter information such as account, their userId ("API User Name" in web app). Save both items.
2. You follow the "consent flow", get their consent, generate a JWT and
exchange for a token.
3. Use the /user_info call against the account
server to get the list of their accounts. If more than one account
in the array, find the one that matches what they entered in the
configuration. Get and save the associated "base_uri". You will
use that for all subsequent API calls.
Your application now has stored the account ID, the admin's "userId", and the base URI to built API URLs.
During business application operations:
Admin is "Bob". Sender is "Jill"
You need to get an access token for Jill.
1. Create JWT for Bob, exchange for access token, make GET /users?email={Jill's email). This gives you Jill's "userId".
2. Create JWT for Jill, exchange for access token.
3. Make API call as Jill, using her access token.
I am building a SPA with a spring on the backend. I am working on signing in with Google, most of it is working already: got the id_token with the implicit flow in the frontend and I sent it and verified it on the backend.
I want to have users with roles and manage that locally (so, no adding info in the oidc provider). What are the options to go from the id_token to having an authenticated user in spring? I did not find any example doing that link manually (id_token-spring_sec_user).
I have checked several sources like the Spring Security 5 presentation at SpringOne https://www.youtube.com/watch?v=WhrOCurxFWU, several SO questions and posts on okta's and auth0's blogs but I am still missing the link.
You will have to create your own (application) specific roles.
Use these steps :
Get authenticated from Google
Access the profile section from google (username, name etc )
Use your own user table to store this info
Create admin APIs in your own system and assign your app-specific roles to the user.
When you login again you will authenticate against google login/password and roles specific to your application .
Create an account or session with the id_token
Check if the user is already in your user database. If so, establish an authenticated session for the user. If the user isn't yet in your user database, create a new user record with default role from the information in the ID token payload, and establish a session for the user. You can prompt the user for any additional profile information you require when you detect a newly created user in your app.
I'm working on a multi tenant project where usernames are actually their email addresses and the domain of the email serves as a tenant identifier.
Now in keycloak I'll have different realms per tenant, but I want to have a single login page for all tenants and the actual realm that will do the authentication to be somehow resolved by the username (email address).
How do I go about doing that?
I found a thread on the mailing list (that I cant find now...) that discussed the same problem. It was something along the lines of - create a main realm that will "proxy" to the others, but I'm not quite sure how to do that.
I think Michał Łazowik's answer is on the right track, but for Single-Sign-On to work, it needs to be extended a little.
Keep in mind that because of KEYCLOAK-4593 if we have > 100 realms we may have to have multiple Keycloak servers also.
We'll need:
A separate HTTP server specifically for this purpose, auth-redirector.example.com.
An algorithm to determine the Keycloak server and realm from a username (email address).
Here would be the entire OAuth2 Authorization Code Flow:
An application discovers the user wants to log in. Before multiple realms, the realm's name would be a constant, so the application would redirect to:
https://keycloak.example.com/auth/realms/realname/protocol/openid-connect/auth?$get_params
Instead, it redirects to
https://auth-redirector.example.com/?$get_params
auth-redirector determines if it itself has a valid access token for this session, perhaps having to refresh the access token first from the Keycloak server that issued it (the user could have logged out and is trying to login as a different user that is served by a different realm).
If it has an valid access token we can determine the Keycloak server and realm from the username or email address in the access token and redirect to:
https://$keycloak_server/auth/$realm/realname/protocol/openid-connect/auth?$get_params
from here, the OAuth2 Authorization Code Flow proceeds as usual.
Else if it doesn't have a a valid access token, the auth-redirector stores the original app's $get_params as session data. It presents a form to the user asking for a username. When the user submits that, we can determine the Keycloak server and realm to use and then auth-redirector itself logs in to the Keycloak server using its own $get_params. Once the auth-redirector gets a call-back, it retrieves the access+refresh token from the Keycloak server and stores them in session data. It then, finally, redirects back to that same keycloak server and realm with the callers original $get_params (from session data). And the OAuth2 Authorization Code Flow proceeds as usual.
This is definitely a hack! But I think it could work. I'd love to try it out some day, time permitting.
Other hacks/solutions are needed for other OAuth2 flows...
The idea from the mailing list is to write a service (let's say auth-redirector.example.com) that has a single input field for email, finds realm based on domain and redirects to that realm's keycloak endpoint (e.g. auth.example.com/auth/realms/realm-name/etc…) while keeping all GET params.
You can find examples of direct login/registration URLs here: https://lists.jboss.org/pipermail/keycloak-user/2016-July/007045.html
One usability problem is that users would have to provide their email twice, I have not yet found a way to pass the username via the login URL.
I am using Graph API to read user information from Azure AD. I am getting all the user information in the response except the password. Is there anyway I can get that?
I am calling this API. (Reference)
https://graph.windows.net/myorganization/users/{user_id}?api-version
As noted in the Graph API References:
The passwordProfile property always returns null. This is to prevent the user’s password from being displayed. You can reset the user’s password by updating the passwordProfile property.
If you are looking to have someone authenticate to your service using their AAD Account, you should either use Federation to have your authentication provider trust the AAD authentication provider, or you can even register your application in our system, and use AAD as your authentication provider.
I hope this helps!