Is there any possibility for users in application View Service Request to see all the service requests under the common vendor.
Example:
User 1 belongs to vendor A.
User 2 belongs to vendor A.
User 1 create a service request, where the record contain vendor A.
The request must be visible to User 1 and User 2 in application View Service Request.
Best regards.
No. Or, at least, you shouldn't go down this road uninformed.
View Service Request is a "self-service" application, designed to support Self-Service licensing. Under that licensing, User 1 is only permitted to see service requests raised by User 1, and removing that restriction is a violation of licensing. If all of your users have (and will only ever have) licenses greater than Self-Service licenses, then this may not be a concern for you.
Related
I have one Salesforce profile and one permission set in Salesforce. As per the requirement, there are two user personas in our Salesforce application.
Persona 1 -> SF Profile
Persona 2 -> SF Profile + Permission Set
To achieve the above configuration using Azure AD auto-provision, we have created two security groups and added relevant business users into those two groups. Currently, we struggling to determine the best approach on how to assign the Salesforce permission sets to the users in the "Persona 2" user group.
You already have Single Sign-On configured in SF, right? At the bottom of the page there's place for just-in-time (JIT) login handler class.
You'd have to write that class but there are some online examples for ... implements Auth.SamlJitHandler. Once you have the class skeleton ready - use System.debug(JSON.serializePretty(attributes)); or something similar to see what Azure Active Directory sends. Last time I used this AAD couldn't send groups info but it could send role(s). So we determined unique sets of users and if role is X - check if the user has permission set X assigned and if not - assign it. We then expanded it to other SF features (groups, queues, user role, profile...). PermissionSetAssignment is the table you need.
If you don't want to write code for this there's always Identity Connect but that's paid and on-premise agent program (I think). No idea if it can work with AAD. But you'll get simple interface for the mapping.
currently I develop a backend based on the microservice architecture.
Unfortunately, I have a problem how to realize the authorization.
So let me explaine my system - there are the following services:
OAuth 2.0 Service (issuing JWT)
Group Service
Some Ressource Services (e.g. ToDos Service)
Every user is in one or many groups.
Each resource (like a ToDo list) also belongs to a group.
That means if some user creates a todo list, that list gets stored in the name of the group.
Szenario:
User A is in group A
User B is in group A and B
User C is in group C
User A creats a ToDo list in group A.
User B modifies this ToDo list (he is allowed to do this since he is also in group A)
User C also tries to modify this ToDo list, but he shouldn't allowed to do this since he is only in group C.
Has any body a great idea how I could realize this in a microservice architecture and keep the dependencies between the services on a minimum?
Certainly, I could ask on every request the Group Service if the user is in the group to which the resource belongs to. But so I get a really hard dependency between the Resource Services and the existence of a Group Service - I like to avoid this dependency.
Another option would be to store all groups, to which the user belongs to, in the access token. But with this option the client has to ask every time the OAuth Service for a new token when the user gets a member of a new group.
So is there any other option how I could realize this szenario?
So, you have three domains:
Authentication: responsible for identifying the user
Authorization: responsible for restricting access to resources
Todos: your core domain
You have done well identifying three bounded contexts, one for each domain and implemented in three microservices (MS). You are conforming to the best practices regarding DDD.
No, your question is how could you integrate those three microservices in such a way that the system is resilient, i.e. its microservices continue to work even if some of the other microservices fail.
You have two options regarding integration (communication between microservices):
Synchronous communication: every time the Todos MS receive a request, it queries the Authorization MS to check if the user is permitted to do what it wants. This has the advantage that is simple to implement but it has the disadvantage that is susceptible to cascade failure: if the Authorization MS fails then this MS also fails. So, this option is not good for you.
Asynchronous communication: somehow in the background, there is some data that is replicated from the Authorization MS to the Todos MS. You have at least two options for this replication to be done: a) in cron or scheduled tasks or similar and b) using a event driven architecture. This has the advantage that provides more resilience but it has the disadvantage that is more complex, harder to implement. This option seems to fit your need.
Further reading:
Building microservices
I would suggest to put the authorisation handling into a API gateway. When there is an incoming request the following steps are executed
1.The API gateway hits the OAuth server to get a transparent token which contains the access roles and groups of the user
2.The API gateway then calls the to do services with the access token , which the to do services use to decide if a particular user is authorised.
The advantage of this integration pattern is that the individual services don’t have to call the group service to get the roles.
I have a client that has chosen to use Business Catalyst for their public facing services, and they want to access roughly four different servers for various activities. The design team has put forth a requirement to be able to log into these various servers using unique login forms on Business Catalyst for each destination.
The first issue is in having a login form within an https page. Business Catalyst has "secure zones" which can be exposed to users that have already logged into Business Catalyst, and I believe there is a way to do so without login by opening up the secure zone to a range of IP addresses. That doesn't feel like a good faith move by any developer (the secure zone is an oxymoron if it has to be exposed to everybody), so let me know if that passes the insanity check. Having the user login to Business Catalyst just so they can login to one of the secure servers is not going to work from a UX perspective.
The second issue is that Business Catalyst states that it must be within a secure zone before it can do any work with the external tools I need it to work with. This might be solved by resolving the first issue, but this has more to do with form queries in general. I have content modules that need to query these servers, without login, to pull non-critical information down as a response.
I have performed a non-exhaustive search over this weekend to try and find a graceful solution to this challenge, but it doesn't appear to be something that Business Catalyst was designed to handle.
For those of you who TLDR;
I need a secure way to login to 1 of 4 servers from Business Catalyst without login to Business Catalyst (Current implementation theory noted above).
I need a way to query non-critical information responses from 1 of 4 servers, again without login to Business Catalyst (Such as returning cost estimate results).
It is not acceptable to have the user login to Business Catalyst, just to pull queries or login to 1 of 4 servers.
It may not be possible to allow a user to access the other servers using their Business Catalyst session handles.
When user logs in to BC, he will get cookie in form VSVxxxxx, where xxxxxx is BC site ID. Content of cookie is hashed active session ID. Then BC exports two web service API - CRM and eCommerce. In CRM web service there's method Contact_IsLoggedIn, which take two parameters - user ID and session ID. Session ID is one from user VSVxxxxx cookie. It returns true/false, whether user is really logged in BC.
Note that BC have bit strange session handling... it lasts for 30min. no matter whether user clicks on site, or no.
Assume I have two web applications and single STS service:
1. Administration portal where I can grant privileges to users.
2. Sales portal where users can do things based on those privileges.
Now assume I have STS that provides security tokens with 8 hours expiration to Sales portal. Token contains claims that carry information about privileges for user, among other things.
Now imagine a scenario where on the Administration portal privilege is removed for the user and change has been saved to the database. Since user is already logged in to Sales portal with security token that has not yet expired, Sales portal will not be aware that privilege has been removed.
Question is - how to handle this scenario. To me the only solution that I can see here is complete removal of STS, but I'm looking for a smarter way to handle this.
Is there a better approach to this out-of-sync issue?
Removing the STS is a little bit drastic :-). You have it for a reason (SSO, federation, etc). You have a few options: decrease the expiration time of the token to a reasonable value for the volatility of your changes (8 hours might be excessive), or move the sensitive authorization information (e.g. privileges) to the app so it is checked each time.
You can do "claims enrichment" at the app level (through a custom AuhtenticationManager in WIF) and still use claims model from your app code.
Technically there's no synching between the app and the STS. The Token is a snapshot of user attributes at the time of issuance and valid until it expires.
We want to implement SSO functionality in our organization, but we're not really sure what our options are, and what the benefits / disadvantages for the different solutions might be.
-We have multiple old ASP(Active Server Pages) sites which should use SSO
-We have multiple ASP.net web-Applications which should use SSO
-We want Sharepoint to use the SSO
-CRM (Biztalk?) integration (Additional information about the user, such as Address, company, etc )
Since we're primarly .net, c#, Microsoft oriented, my first idea was to use Active Directory.
I've also noticed that there is something called ADAM (Active Directory Application Mode), and ADFS (Active Directory Federation Services), but I can't really say I understand when/where these should be used.
Here is a brief overview of the different web-applications
-"My Personal Page" : User log's into an application where they can modify their personal information along with their company-information and their employees. (Asp.Net)
-E-learning application (ASP)
-CMS system for web-publishing (ASP.Net)
-Sharepoint sites
I haven't really been able to find any articles that can tell me "AD is a great choice! , you can use it everywhere", so If anyone has got any experience /feedback to give me on this, it would be really helpful.
Also: How should rights/roles be managed ? Should all access/rights/roles for each application be stored in AD, or should this be stored in the applications themselves.
IE : AD stores the roles:
"Cms" <-allowed to login to the cms system
"Cms.Article.AddAllowed" <-allowed to add article
"Cms.Article.DeleteAllowed" <-allowed to delete article
Or should this information be split up, so that AD holds information about which applications the user is allowed to log into, while the application itself holds information about what the user is allowed to do within the application when logged in
AD rights:
"Cms" <-Allowed to login to the cms system
Cms rights:
"Article.AddAllowed" <-allowed to add article
"Article.DeleteAllowed" <-allowed to delete article
So, when the user logs in, they are first authenticated against AD, and if that goes ok, the rights for the Cms application is fetched from a rights-table in the cms system ?
What are my options ? What other solutions other than AD do I have ?
Thank you for any feedback, its much appreciated !
We have done something similar in my organization. Here is the overall flow:
User requests web page
User is redirect to login screen along with SAML request
User authenticates against Active Directory
User is passed back to request web page with SAML response
User group/rights information is retrieved from database
If user requests page from another website same process occurs however if the user still has a session or selected the "remember me" feature then user does not have authenticate and gets logged in directly.
We use Sharepoint, but have not setup SSO yet. I believe Sharepoint gets the rights of the user from its own backend database/system. We also have a homegrown system to update user's groups/rights. I know Sharepoint can use web services so you could possible update Sharepoint when using a centralized user management system (of course you'd have to build that). The main thing is finding out where Sharepoint gets its information about the user and how you can tie your existing system to it...
I wouldn't rely on Active Directory to store group/rights information. It a pain to deal with compared to a database and is not flexible. It's fine for authentication and password management you just have to tie the user on Active Directory to your database system.
As far as I know, Active Directory is only practical for users within your domain. You would need an administrator to manage all those users and to add new users.
I've been working on a project myself where I wanted users to sign in, just to know their identity. I did not even care about their access rights but just wanted an identity on every visitor, something more reliable than an IP address, cookie, session key or whatever else. So I first asked my administrators if I could use Active Directory for this project. Sure, I could. But the webhost wasn't connected to our company domain so I would end up with only one user. Yeah, my administrator is a bit sarcastic sometimes.
So I started to explore SSO options. OpenID like this site is a good option and you could even implement your own OpenID server and require all visitors to sign on there first. It's a very powerful technique and you have less worries about managing users in your project. (Because the OpenID provider takes care of this.)
However, I ended up using CardSpace instead. :-) With CardSpace, every user can create their own user-token and store it on their own system. To log on, the website just asks for the card and the user just clicks on it. Those cards can be migrated to other systems but tend to be tied to a single computer and user, most of the time. (Although users can share a card!)
Rights and Roles are a different matter than Authentication. People always think they're connected while in reality, these are two different things. First, use OpenID or CardSpace or another authentication technique to verify the identity of the user. It doesn't matter how they're identified, you just need an identifier.
Next, you need rights and roles. Roles are basically just user-groups and you can connect an identity to a group. Or to multiple groups. And rights would be linked to roles, not users. But how you're going to divide these roles just depends on the applications. Just remember that someone who is an administrator in your version control system should not be an administrator in your customer database. Roles tend to be application-defined, thus every application could manage their own rights and roles and just needs a way to link these to an identity.
I myself just needed identities so I knew whom to blame when something ended up messed up. Then again, when there's only 5 users, things tend to become quite simple.