In WSO2 API Manager, we try to access Subscriber UI and Publisher UI through SSO. The SSO connection works fine, but Admin gave a special user the publisher creator permission. but If that user accesses the Subscriber UI again through SSO, the newly given permission(publisher creator) is lost and reset to the initial setting. What should I do in this case?
As per the description, I believe that you have created multiple Identity Providers to log in to Publisher and Devportal. Also, have enabled the Just-In-Time provisioning at the Identity Providers.
If yes, try adding the following configuration in the APIM's deployment.toml and try out the scenario
[authentication.framework.extensions]
provisioning_handler = "org.wso2.carbon.identity.application.authentication.framework.handler.provisioning.impl.SystemRolesRetainedProvisionHandler"
The default provisioning handler removes any additional roles that have been assigned to the logged-in user performing the sign-in process. The above-given Provisioning Handler is an extended version to not remove the additional (custom) assigned roles from the user using the login process.
Related
I am making an admin tool page to allow admins to change users email for when they change or set their account to deactivate so they can not access the site anymore. Everything I have looked at seems to be using 'CurrentUser' but this will not work due to the fact they will be logged in as themselves which is marked as Admin level so they have access to the tool. So is there any way to change a users email for authentication without logging in as them?
If the Firebase Authentication client-side SDKs had an API that allowed you to change the email address of anyone but yourself that'd be a major security risk.
This is the reason an API to update any user by their UID only exists in the Admin SDK, which can only be run on a trusted environment as it requires full administrative access to your project.
If you want to expose this functionality to specific users of your app, you'll have to wrap the relevant call of the Admin SDK into a custom endpoint that you then call from the app. Just make sure to check that the user is authorized, before changing some other user's account.
I created a user with username:aggr1. When I log in to the dev portal with aggr1 credentials, I can access all of the published APIs. How can I force this particular user to only see two or three APIS in Dev Portal?
Thanks
You can maange access to APIs through roles.
When creating an API, on the first page you have a dropbox "Access" (or "Visibility" orsomething like that) with default value All.
You can list roles, which are required to see the Api in the dev portal. And then assign (or not) the roles to the user.
By default APIs are set to public and any user who logs into the devportal can see the APIs. You can set role-based visibility or based on domain. Please refer the documentation - https://apim.docs.wso2.com/en/latest/learn/design-api/advanced-topics/control-api-visibility-and-subscription-availability-in-developer-portal/#control-api-visibility-in-the-developer-portal
I am building a Firebase application (using Firestore) which needs to support custom authentication via single sign on through a third party system.
In the past, I have done this type of integration with my own authentication system. To do this, I installed the Firebase Admin SDK on my own server and used the secret key to sign a JWT that was passed back to the client, which then could be used to grant access to the Firebase application.
However, since the Admin SDK grants full access to the Firebase app, I have concerns about handing those keys over to another party. Is there a way that I can provide a secret key that grants more limited privileges to the third party? I want them to be able mint JWTs for their users to access the app, but I don't want them to be able to directly read/write from my database.
I think I've solved this by taking the following steps...
1) Access the Firebase project's IAM admin tools
2) Create a new service account for the project in the "Service Accounts" section.
3) Create a custom role in the "Roles" section and give it access to all of the Firebase Authentication privileges: https://firebase.google.com/docs/projects/iam/permissions#auth
4) Assign the custom role to the service account in the "IAM" section of the admin interface.
5) Go back to the "Service Accounts" section and create/download a private key for this service account.
6) Use this key as the credentials for the Firebase Admin SDK and create a custom token using the process detailed here: https://firebase.google.com/docs/auth/admin/create-custom-tokens
The SDK should permit creating a custom token, but it will return errors when trying to do other actions such as accessing the project's database.
I want to change user password form admin. Users are login with firebase email and password option. Admin is also login with firebase. How can change the user password with web api?
There is no way to change another user's password with the client SDK.
Firebase Authentication doesn't have any concept of an admin user. That means that it can't grant special privileges to a user that you consider an admin.
There is however an Admin SDK, that runs with administrative privileges, and has the option to change the password (and other profile data) of any user in the project. This SDK is meant to be used on a so-called trusted environment, such as your development machine, a server you control, or Cloud Functions.
You could wrap the Admin SDK in an API endpoint that you can call from your web client code. Just be sure to check in the custom function whether the user is authorized to change the password.
I'm developing an ASP.NET MVC application. I need to support multiple authentication mechanisms (this app is used by multiple customers, each with their own preferred authn provider). One auth provider will be Active Directory. The AD integration for authentication is straightforward and I have no problems with that.
For authorization, roles will be stored in a local database (NOTE: we cannot use Active Directory groups for doing authorization - roles need to be local application roles because we support multiple authn providers and AD admins won't want to create custom groups in AD just for our app). My expectation is that we will need to create "stub" user accounts in our local database in order to do the User-is-assigned-which-Roles mapping. These stub user accounts will also be used to indicate which users are authorized to access the application (not everyone in the AD database should have access).
The anticipated flow of control will be:
User accesses login page > enters credentials > posts credentials to app server.
The app validates the credentials against AD. At this point, we know if the user is authenticated.
The app checks the user's SID to see if a "stub" user account with that SID exists in the local database. If not, the app displays an "not authorized" error message to the user.
The app will look up roles for the user in the local database user-is-assigned-which-roles table.
User identity info including roles will be stored as claims and the app will use typical claims based authorization (i.e. ClaimsAuthorizationManager).
My question is what is the best way to create "stub" user accounts into my local database? My guess is that we should use some sort of AD export script to export AD accounts for those users that should be granted access to the ASP.NET app and then import those users into the local database (NOTE: I expect that the stub account will contain minimal info - perhaps just the user's SID from AD and maybe the username).
A batch export/import is probably OK as an initial deployment process. After the app is up-and-running and new users join the organization, I expect a more user-friendly mechanism will be desired for granting a new user access to our app (other than exporting/importing the new user's account from AD to our local database). My guess is that we'll need some sort of user browser screen so that an admin in our app can browse the AD directory, select a user, click a button and then have that user's "stub" account created automatically in our app.
Has anyone implemented an application with similar requirements? If so, how did you bootstrap the creation of "stub" accounts in your local database? Is there a better way to address these requirements?
Please feel free if this can Help You Custom Annotation Authorization
It's only a workaround, or just an idea, not a solution...
To use it you only need to use Annotation in the controller
e.g.
[ARQAuthorize]
public class BlaBlaController : Controller .....
I am currently implementing a similar solution. Here is how the application works. I'm using ASP.NET MVC 5, ASP.NET Identity 2.2.1.
I am using the Identity framework to manage users and roles within the application. The user goes to a login page, enters their credentials. The application checks against the application DB to see if the user exists. If not it throws an error that the user doesn't exist in the database. If the user exists, it authenticates against AD. If authentication fails they get an error message, if it doesn't fail I create a ClaimIdentity from the user out of the database (not the user in AD) and pass that to my SignIn method.
My user in the application DB has the same username as the AD username and I use that as my stub. I also include the domain of the user in the DB as well in the case that I might have multiple domains I need to support. With Identity, don't forget to also populate the SecurityStamp field with a guid.
The plan is to bulk import the users and permissions from a spreadsheet and I have some standard CRUD actions created to allow creation of individual users and assigning of roles after that.