We're currently evaluating SAP Business Objects XI 3 for a front end reporting solution, but I'm not happy that we will need to create a new set of logins that will be managed independently from our existing website. We have an authentication API that our various applications all hook in to, so we effectively get single sign on, and single account management.
Is there a way to write a custom authentication plugin for SAP BOE 3? I've googled for information and have come up empty handed. Links to documents would be handy also.
The solution that we use for this problem is to have a seperate password management page built into the HR space that will change all the user's passwords to the same thing. So there is one input for username and pass that changes the global password for a user and then it runs through and changes all the different SAP ones that are needed.
Not really the answer you are looking for, but it is somewhat of a solution.
Related
What is the best way to restrict the scope of a connected app to a set of objects? My current solution is to use the Manage user data via APIs scope but that still grants more access than required.
A solution I see frequently is to create a user with a restricted profile and connect with that user but then you lose context of actions made by users in the connected app so this solution doesn't work
Tricky, you typically don't. (consider posting on https://salesforce.stackexchange.com/, there might be a clever way I didn't think of).
You can flip the connected app from "all users can self authorise" to "admin-approved users are preauthorised" and then allow only certain profiles / permission sets to use the app. But the bulk of it is "just" enabling the connection via API and cutting it to say Chatter only or OpenId identifiers. And that's already an improvement compared to SOAP APIs where you don't have scopes and the app can completely impersonate the user, do everything they can do in UI.
Profiles/permission sets/sharing rules are "the" way even in not immediately obvious situations like Lighting Connect Salesforce to Salesforce or Named Credentials access to another org.
If you can't restrict the visibility with profiles and access to all tables user can see is not acceptable...
you could create series of Apex classes exposing certain queries, updates etc and grant profile access to these classes - but without full api access? You could even let them pass any SOQL (evil) but use with sharing, WITH SECURITY_ENFORCED, stripInaccessible + custom restriction on tables before returning results
you could look into https://developer.salesforce.com/docs/atlas.en-us.238.0.apexref.meta/apexref/apex_class_Auth_ConnectedAppPlugin.htm although I suspect it's run only on connect, not on every request. So at best you could deny access if user has right to see some sensitive data, not great
if there are few objects you need to block updates if done via app - Quiddity might be the way to go. Throw error in a trigger if action started from REST context?
give the Transaction Security trailhead a go. If it looks promising (there's way to check "application" and "queried entities" according to this) - might be a solution. You'll likely have to cough up $ though, last time I checked the cool bits of event monitoring & transaction security were hidden behind an extra paid addon (standalone or bundled with platform encryption and Field Audit Track into Salesforce Shield solution)
2 logins? dedicated user for querying stuff but inserts/updates running as your end user?
I am fairly new to coding in the .Net environment. I am having trouble finding "real-world" examples on authentication/authorization using Identity. Most examples I come across are primarily textbook examples that use the ASP .Net registration template.
I am trying to find guidance on where to look (yes, I Googled and I get very unrealistic/unusable use cases or "classroom" examples) or how to do this.
I work for a small school and I am trying to build an application (possibly Blazor - just experimenting with various technologies now) that allows both students and employees to login into a portal and view their relevant data. I have an Employee table and a Student table based on POCO classes. When I add identity to the project it creates Users and Roles tables as well.
I would like to have the "Users" table based on the Student and Employee tables - not have a separate users table. I do not want to have a "registration" option either. I would like the option for an Admin (which would fall under an "Employee") to be able to add users, but not use a registration page.
How would I implement Identity and Roles without using all the extras added? I am using .Net 5.0.
Thank you for your time and pelase forgive the English - it's new to me as well.
I understand what you're trying to do. It IS possible to Create a Custom AuthenticationStateProvider
But unless you have a VERY robust database already, I wouldn't do it. Getting the default system set up and migrating users will take at most an hour. Setting up your own custom authorization system is likely to take you MUCH MUCH longer.
Having different users in different tables is not a good design plan. They all have names, phone numbers, e-mails and so on-- put them on one table.
Hi Derrick and welcome to the community! #Bennyboy1973 is correct, in that both your Students and Employees are all "Users", so they should all be stored in the same table. To add to that response a bit, probably the simplest way for you to manage them is by using Roles, so the Students could be in one role and the Employees could be in another. By having a role attached to each, you can then use the roles as a filter in your queries and you could also restrict the access and actions each type will have based on the role they are in.
Regarding having administrators add the users to the database without public access, this can be done as well. Once you get the default identity system up and running, you can scaffold out the whole system so it can be modified, and probably the easiest way to achieve what you are after is to then modify the default registration (signup) page so that it requires the user to be authenticated to reach it, and then implement a confirmation email to activate each new account.
There are a few things with this approach that you need to be aware of as well.
Since the admin will be setting up all the other user accounts, you should modify the email confirmation chain to require a password reset at some point. The administrators can have access to the user's information as needed but shouldn't have the user's passwords.
Identity Server will store passwords in an encrypted format, and you'll need an initial user in your database. What this means is that you will have to "seed" an initial admin user into the database that you can use to sign in and get started with everything else. You'll have to research how to do this, as it isn't as simple as just accessing the database directly and adding the user and roles because of the encryption. The program you build should be designed to do this for you on either the first run or if you are connecting to a new database, using a username and password that you know. It will then store the user properly that you can use to sign in as Admin, then change the admin password. This makes the whole thing more secure.
This all sounds like a headache, but it's worth it to work through and know how it all fits together. The, as mentioned in other answers, you can migrate existing data into the database.
Hard to find a meaningful title. I hope I get clearer now.
I'm building a service which is similar to doodle regarding the authentication model. The user can "create" something (using a form). There will be two different views. One for the creator where he can modify his settings and another one for public access.
I don't want to force users to register / log in. So I came up with a URL structure like doodle has:
/{some-id} -> public access
/{some-id}/admin/{some-token} -> settings page for the owner
The question now is how I can deal with this best. Currently I pass the token to all admin related Methods. But I don't feel comfortable with that.
I also thought about some server side session. I found two meteor packages but they are both not actively maintained anymore.
Another idea was to misuse the built in user management but without the user to recognize it. But I don't think that's feasible.
So now I'm asking you if you have a nice way of dealing with this. I hope I made clear what I want to do.
There are many ways of doing it. One way is to reuse Accounts package.
You user id is {some-id} and the password is {some-token}.
When you create new page. You create new user on server side using Account.createUser.
When you enter url /{some-id}/admin/{some-token}Meteor.loginWithPassword.
I have an AIR application and would like to connect to an LDAP server to obtain some information for a particular user.
The url is something like ldap://ldapservername:389/
I would like to pass the userid/Name as the parameter and hope to retrieve the Full Name, Email address etc.
Can you please provide suggestions regarding implementing this? A Windows specific solution is also fine with me.
Adobe AIR does not have built-in support for LDAP. All online examples go through a server for LDAP integration.
Sample: Performing an LDAP query for role resolution
http://www.adobe.com/devnet/livecycle/articles/perform_ldap_resolution.html
Short of using a server, you're limited to two options, neither of which is good.
Completely re-implement the LDAP protocol in AIR. I think this is feasible, but is a huge undertaking. With Alchemy you theoretically could recompile an existing C library to work with AIR, but I don't know how well that will work for this particular use-case. Plus it's a research project, not production ready.
Embed a native application. With AIR 2.0 you can include a native application written in C or .NET or whatever and launch it to perform your LDAP calls. The only way to communicate with this other process is through stdin/stdout so it's not easy to transfer complex/typed data, but it's feasible.
AIR is not suited for all applications. If all of your application's requirements can be fulfilled within AIR's API, then it's great. But if you need to do something not directly supported by AIR and don't have a server component, you're better off not using AIR.
You will probably need to do the usual LDAP stuff. Either start with the full DN of the user (uncommon) or search for it.
Bind to the LDAP directory as a proxy user, or as an anonymous bind. Query for ATTR=VALUE where ATTR is something you define as the unique value in the directory. Traditionally this is uid in LDAP servers. For Active Directory probably would be better to search for ATTR of sAMAccountName. Keep this as a setup parameter for the admin, since it will make it easier on different LDAP backend servers.
It might be mail, and the login value the user would enter is their email address. Depends on the use case. But leave it configurable to be flexible.
Then the search should return one value, with a full DN, then you want to bind as that user with the full DN and the provided password. I like the approach of binding as the user, instead of comparing the password, since then you increment any Last Login attributes, or the like, making it easier to detect account inactivity from the directory administrators perspective.
I need a Global variable/class that stores some basic information about the currently logged in user including that user's preferences, security rights, UserID, etc. This information will be needed by any/every part of my application.
In the past I have either used a Public variable/class in a vb.net module for this purpose. I'm trying to get away from my old ways of doing things and was curious what people currently do for this functionality.
I am thinking a singleton or 2 regarding preferences and security but am not sure if that is the best way to go.
EDIT: This is an n-Tier WinForms application.
In my ASP .net web app, I store an object that contains login information for that user in the Session Cache. That is one way.
If you want different "global variables" for each user, then sessions are the way to go (as Russell mentioned). If you want variables that are the same for every single user, then Application variables are what you want.