We use OpenAM to manage users that have access to multiple applications. Access to all is controlled using SSO through OpenAM.
Some of the applications need to have specific (minimum) password policies. When a user has access to more than one application for which there is a defined unique policy then the applied policy for the user password should be the most stringent.
How do we enforce this? In effect can we define a priority order for password policies?
Cheers
Daryl
Related
I am looking at the documentation of service principals , and come across these phrases
It's important to remove old service principals for the same reason that you delete old user accounts: attackers might gain access to their keys. It's best not to have credentials that aren't actively used.
You might wonder why you need to create this whole new type of object
just to authenticate a pipeline, when you have user accounts that work
perfectly well. User accounts aren't designed for unattended use. The
authentication process for a user account often checks that a human is
the entity that's trying to sign in. Increasingly, organizations use
additional security checks during authentication. These checks include
MFA, CAPTCHA checks, and inspecting the device and network that the
user is using so that they can verify the legitimacy of a request to
sign in.
It's also a bad idea to save your username and password anywhere, because someone else might get access to them and then use them to impersonate you.
In "both" theories, it seems it is not a good idea to keep / share service principals ( aka passwords ). Is it only reason that passwords are not designed for unattended use we should use service principals which offers secure measures on a case to case basis ?
As per the Official Microsoft Documentation,
When you have applications, hosted services, or automated tools that needs to access or modify resources, you can create an identity for the app. This identity is known as a service principal. Access to resources is restricted by the roles assigned to the service principal, giving you control over which resources can be accessed and at which level.
The user accounts and passwords are not designed for unattended use. Service princpals can be used to give the access to the resources based on the Role-based access control(RBAC).
What service principal object exactly do is it sets the information about a particular app and its resources access.
If you want to avoid the need to manage the credentials you can use Managed Identity.
Reference:
https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals#service-principal-object
I am looking to design an MFA policy in B2C that has a longer refresh token window (let's say 1 day) to avoid frequent MFA challenges, but have an elevated access portion of the application that requires more frequent MFA challenges because of the nature of the operations.
According to https://learn.microsoft.com/en-us/azure/active-directory-b2c/session-behavior?pivots=b2c-user-flow, it appears I can accomplish this by creating 2 B2C custom policies with different refresh token timeouts and set the session behavior to Policy.
Policy - This setting allows you to maintain a user session exclusively for a user flow, independent of the applications using it. For example, if the user has already signed in and completed a multi-factor authentication (MFA) step, the user can be given access to higher-security parts of multiple applications, as long as the session tied to the user flow doesn't expire.
My questions:
Is this the appropriate design to accomplish the goal or is there a more preferred approach?
Will this result in a user being double-MFA'd if they log in after 2 days of inactivity and immediately navigate to the elevated portion of the application? I think the answer is 'Yes', but want to confirm. Is there a way to avoid this double-MFA and have the policy recognize that an MFA was already triggered within its own window?
You might try setting Single sign-on configuration to Application and use the same with your 2 custom policies. This will allow the user SSO to be shared for any policy being used and should allow session expire time to be controlled by each one of them. Also, if user has passed MFA authentication it should not need to do it again.
I wanted to know if there are provisions in SAML based Single Sign-On wherein I could authenticate using token provided by IdP and then once authenticated the authorization i.e. what roles/privileges the user has must be handled at the application end. This is entirely from an Azure Active Directory perspective.
Provisions in SAML based Single Sign-On
If users exist in your IdP but are not in your instance, SAML user provisioning can automatically create the users in your instance's User [sys_user] table.
SAML user provisioning is supported for SAML 2.0 Update 1 when
Multi-SSO is enabled.
How SAML user provisioning works
When SAML user provisioning is enabled and the system encounters a new user that is not in the instance, the instance automatically creates a record in a temporary table with the name u_import_saml_user_, where is an automatically generated text identifier. The system also creates transform map that specifies the data relationships between the import table and the User table. Each IdP in identified in the system has its own transform map. The transform map is created once for each IdP. Administrators can update it as necessary.
When the user logs in, they access an IdP to log in.
The system presents a list of all IdPs that are able to use SAML
user provisioning. If there is only one IdP that can use SAML user
provisioning, that one is used automatically.
If none of the above conditions are true, the system uses the
default IdP.
Administer SAML user provisioning
To update the User table with the users in your IdP, you must first set up field mapping and then enable user provisioning through Multi-SSO IdP settings
Roles/privileges
For roles privileges and User administration you could refer here
Some Benefits of Provisioning
Implementing Just-in-Time provisioning can offer the following advantages to your organization.
Reduced Administrative Costs: Provisioning over SAML allows customers to create accounts on-demand, as part of the single sign-on process. This greatly simplifies the integration work required in scenarios where users need to be dynamically provisioned, by combining the provisioning and single sign-on processes into a single message.
Increased User Adoption: Users only need to memorize a single password to acces
s both their main site and Salesforce. Users are more likely to use your Salesforce application on a regular basis.
Increased Security: Any password policies that you have established for your corporate network are also in effect for Salesforce. In addition, sending an authentication credential that is only valid for a single use can increase security for users who have access to sensitive data.
To know some more idea You could also have a look on here
Some key resource for your reference
Configuring Azure AD as a SAML IdP
SAML Guide Line
How does SAML work? IDPs & SPs
SAML terms and their purpose
Hope It would guide your way around regarding SAML implementation. Thank you very much.
Is there a way (either in the portal or otherwise) to restrict access to policies? For example, I can specify what sign-in policy I want to use in my application (say, only Google and Internal logins) but if a developer changes the policy value in the application to call a different policy that allows Facebook logins (which we don't want but the policy does exist in the portal), how can we enforce security on this situation? Is there a way we can restrict access to policies for only applications that are allowed to access them?
Is there any way to limit the access of an integrator key to a specific security group in DocuSign? For instance I only want to be able to get envelopes created by users who are part of a specific group. Is it possible?
Impose limits on your app by making the individual users log into it. Eg use Authorization Code Grant flow so an individual user will log into the app and then the app will have the individual user's permissions capability.
You should only create a "service integration" if there is no way for a user to log in.
The integration key enables your app to use the api. The integration key does not grant any privileges per se. Privileges are granted by the login used.