Where does WebSphere Portal 8.5 store user registration data that is entered through sign up form? I.e. user id, password, first, last name, email etc.
WebSphere Portal doesn't store any user info on its own.
It uses PUMA and VMM to talk to users store registry. See more here http://www-01.ibm.com/support/knowledgecenter/SSHRKX_8.0.0/plan/plan_vmm_int.dita.
Guess you can look at http://public.dhe.ibm.com/software/dw/websphere/PUMA_scenarios.pdf to figure out how you can retrieve user information from the user registry.
This data is stored in PUMA.
In the WAS console, you will be able to view the LDAP configurations.
Login to the WAS console and go to Security > Global security > Federated repositories > Manage repositories > PortalLdap
Under LDAP server, the "Primary Host Name" will show the server where PUMA is configured.
Related
We have an application which parses the Audit Logs emitted by Azure AD. More specifically we are parsing the 'Update application' log to detect when a new Role has been added to an Application (see example below).
We would like to find out more information about the "DirectAccessGrantTypes" and "ImpersonationAccessGrantTypes" fields. If someone can point us to documentation for this that would be great.
[{"EntitlementEncodingVersion":2,"EntitlementId":"654a4f1f-1b7f-4354-a6d6-fcf7346af0ec","IsDisabled":true,"Origin":0,"Name":"Data Manager","Description":"Manager for test app","Definition":null,"ClaimValue":"DataManager","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[20],"ImpersonationAccessGrantTypes":[],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]},{"EntitlementEncodingVersion":2,"EntitlementId":"3d03256d-cf0c-4553-b8af-98d7ebbee1f2","IsDisabled":false,"Origin":0,"Name":"Application Manager","Description":"Admin for test app","Definition":null,"ClaimValue":"ApplicationManager","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[20],"ImpersonationAccessGrantTypes":[],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]},{"EntitlementEncodingVersion":2,"EntitlementId":"88d0d3e3-b661-4760-aea3-f4548db1ff96","IsDisabled":false,"Origin":0,"Name":"Read","Description":"Allow users to add a admin consent","Definition":null,"ClaimValue":"Read","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[],"ImpersonationAccessGrantTypes":[{"Impersonator":29,"Impersonated":20}],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]}]
From article > View reports & logs in entitlement management - Azure AD | Microsoft Docs
When Azure AD receives a new request, it writes an audit record, in
which the Category is EntitlementManagement and the Activity is
typically User requests access package assignment. In the case of a
direct assignment created in the Azure portal, the Activity field of
the audit record is Administrator directly assigns user to access package, and the user performing the assignment is identified by the
ActorUserPrincipalName.
Application Impersonation is basically an administrator-managed, not user-managed permission.
Impersonate access grants logs gives information ex:count., of users given consent by the admin to access the application to impersonate user.
ImpersonationAccessGrantTypes gives count or info of access grants by admin on behalf of user whereas DirectAccessGrantTypes gives info about the users who directly access the application ,as they are already assigned by admin.
Reference:
Multiple Client applications authorisation to WebApi (microsoft.com)
On guest user login on redirect URI I got an error:
AADSTS1000031: Application {App name} cannot be accessed at this time. Contact your administrator.
I'm using multi-tenant approach. The authorization URL looks good and it redirects me with such an error.
But I can't find any description of the error or configuration in the azure related to this error.
Also, "normal" users can log in without any issues.
I have such configuration in my Azure App:
Could you please advise how can I enable guest accounts support here?
This error can occur if you have not granted admin consent.
Go to Azure Active Directory within the Azure portal.
Go to Application registrations.
Select the Application based on the App-Id.
Go to API Permissions.
Click Grant Admin consent.
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/grant-admin-consent
Has this SSO been setup as an Enterprise application?
Or are you just trying to get a guest user logged in to your tenancy as a guest?
If it is the later just create a new Guest user within your tenancy, make sure you have the rights to to do this first.
Then have the guest user accept the email invitation they receive.
Confirm within Azure they have accepted the invite.
Also make sure they are using the same email address as the invite was sent to and not an alias, which can cause confusion.
lets say I have two on-premise domains (DomainA.org, domainB.org) and one tenant (domainA.onmicrosoft.com). Both domains are sync thanks to Azure AD Connect, so user from domainA can log to office.com, there is no problem. Hoever user from domainB getting this "Error validating credentials due to invalid username or password.", and when I changed password from portal.office.com for this user from domainB. I can log with this new password, but only to office365 services, its not sync to On-prem.
And another wierd thing is, that I cant change password for users from domainA.
Do You know where the problem is?
Thanks
I understand you have synced your 2 domains to Azure AD through Azure AD connect . Initially you have registered both the domain in Azure AD and verified both. Kindly check what kind of authentication you were using for Domain A since you were not able to change the password from Azure End. If you have federated that domain it is not possible to change from the cloud. If you were using password hash synchronization then the authentication will happen if cloud and you can change for managed domain.
I request you to go through this article about password writeback . When you are getting an error message while logging before resetting the password kindly note the correlation ID and time stamp and need to get a support ticket since it will be due to multiple reasons.
I've connected my WSO2 api manager with external ldap i.e. Microsoft Active Directory.
I have a following user in my Active directory :
Username : WSO2 Admin
User logon Name : WSO2.Admin#india.test.com
NT logon Name : INDIA\WSO2.Admin
When I'm setting the Admin role for my user's Username in user-mgt.xml file. I'm able to login into the the WSO2 admin console with Username i.e. WSO2 Admin only and I'm also able to see all the users from active directory but If I'm trying to login into management console with the actual logon name i.e. india\WSO2.Admin or WSO2.Admin#india.test.com It's showing me login failed error.
<AdminUser>
<UserName>WSO2 Admin</UserName>
<Password>xxxxx</Password>
</AdminUser>
Can somebody please help me solving this?
In WSO2 carbon (base for all wso2 products, not just apim) realms and domains are having different meaning.
e. g. the domain #india.test.com in the carbon logon form denotes the tenant (the default tenant is carbon.super. You may try to log in with WSO2.Admin#carbon.super in theory it should work. (I did not try it myself)
as well the realm (in form of realm\username) hints the carbon to use a secondary userstore with specified realm parameter (I may be wrong in this format, if someone knows for sure, feel welcome to correct me)
I believe full domain should work with a Kerberos authenticator (used for applications, not for the Carbon management console), but this authenticator has been reworked and improved in current versions, so I don't know current state)
I spent a long time yesterday to configure for my CouchDB instance in order to create a little app and letting CouchDB manage authentication and authorizations for me.
So I ended up with something like that :
On top of everything I've got a server admin, who basically is god on my CouchBD instance.
Then I created a database named "mydatabase" (for example) and added the role "mydatabase_dba" as admin and also the role "mydatabase_user" as reader.
I also created a database named "_users" which contains all the database admins and users with their roles and also a design document named "_auth" which manages authorizations.
Only the server admin is admin of this database, and I added users with role "mydatabase_dba" as readers. Then, for those of you who knows about it, I modified the "validate_doc_update" field o the "_auth" document so that users with role "mydatabase_dba" can only deals with users with role "mydatabase_user".
So, to summarize at this point :
server admin is still god
users with role "mydatabase_user" can connect to "mydatabase" but they are just readers
users with role "mydatabase_dba" are admins of "mydatabase"
users with role "mydatabase_dba" can connect to database "_users" where they are readers
users with role "mydatabase_dba" can only manage users of role "mydatabase_user" in "_users"
Hope this is clear :D
What I can do now is create an application that will not manage users itself, but let users connect to CouchDB directly (transparently).
The problem come when it deals with users creation/update/deletion.
Because only users with role "mydatabase_dba" can access to the "_users" database and work on users with roles "mydatabase_user", I need at some point to connect to CouchDB as this db admin.
I have two solutions :
Create a user interface into my app that will let the admin connect and do what he has to do
or
Make some more code and let the app do it automatically, this is the solution I prefer, but the problem is : I have to store the admin credentials...
Sorry for the long introduction but I had to describe the landscape first :)
I created a post yesterday about how I could secure the connection between my app and the CouchDB instance : here
The solution I was given is to use HTTP over SSL (/TLS) to secure the communication. I'm okay with that, but now I have another concern, maybe I'm paranoid, but because my app will need to connect as "mydatabase_dba", I have to store its credential somewhere.
But how to store them securely ? As said in my previous post, even if I store the hashed password instead of the plain text password, if an attacker access my app source code, he'll have my admin credentials...
An application should never have an administrative rights. It should only be given the bare minim rights it needs to function. If the application needs some administrative rights, make sure it has as few as possible. Other than that, most of the time these credentials are stored in plain text in some file that only your application can access.
Never commit this text file into your source code manager (Subversion, Git, etc.)! Placing the file into a running system must be a step in the installation procedure.