The docs
https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-reference-sso#noopssosessionprovider
say "As the name dictates, this provider does nothing. This provider can be used for suppressing SSO behavior for a specific technical profile."
What is the difference between invoking SM-Noop at a given location in the custom policy and a situation where I would not invoke it at that same location?
Thank you
SM-Noop explicitly states to not include the technical profile as part of the session. If session management technical profile reference is absent from a technical profile, the result should be the same, but better to be explicit.
Related
I've been reviewing some example custom policies that revolve around account linking which I would like to integrate in to my own set of policies. I've found the Azure B2C documentation lacking when it comes to explaining the difference between an 'alternative security' and 'user identities'.
The account linking policies I've been reviewing interact with a user's collection of identities via a handful of claims transformations (e.g. CreateUserIdentity, AddItemToUserIdentityCollection, RemoveItemToUserIdentityCollection and GetIssuersFromUserIdentityCollectionTransformation). The only place these claims transformations appear to be documented is in a random github issue comment posted more than two years ago. All the sample account linking policies also haven't been touched in a couple of years.
On the other hand, the base policy from the default starter packs use documented claims transformations to interact with a user's collection of identities (or at least to add an entry there when a user signs up via social idp). There are claims transformations documented here that match all the user identity ones above (e.g. CreateAlternativeSecurityId, AddItemToAlternativeSecurityIdCollection, RemoveAlternativeSecurityIdByIdentityProvider and GetIdentityProvidersFromAlternativeSecurityIdCollectionTransformation).
The distinction between these two concepts is really not clear to me. Why are there seemingly two ways (along with a parallel set of claims transformations), to interact with identities?
Can account linking can be achieved using the documented alternative security claims transformations? This would go against what appears to be the recommendation to use userIdentities claims transformations with account linking, but using years-old samples employing undocumented features really doesn't fill me with much confidence.
Yes, you can use either.
They are essentially two different naming conventions that refer to the same base structure.
Refer this and this.
This element is part of multiple samples, e.g. https://learn.microsoft.com/en-us/azure/active-directory-b2c/add-ropc-policy?tabs=app-reg-ga&pivots=b2c-custom-policy
Yet it's not explained anywhere, and it's missing from reference documentation.
It is explained in the Azure B2C custom policy starterpack.
Claims are presented to the Relying Party Application in a token
generated by CPIM. However, a Technical Policy may state, using a true
or a false for this element, that the original assertion which was
returned from the Claims Provider(s) must also be preserved so that if
needed, it can be looked at by Relying Party for auditing or
diagnostic purposes.
I want to release my application in play store and app store.
But, That store require PrivacyPolicyUrI But I don't use signup system
And most application has terms of policy in their signup view
it is essential?
So...
PrivacyPolicy is required for non-signup application, too?
Terms of policy is required even if I'm just developer not company?
Yes, a Privacy Policy is required even for apps that do not require sign-up. However, a sign-up screen is good as you can use the clickwrap method of getting active constent from users to accept your Privacy Policy.
The requirement of a Privacy Policy is due to sensitive permissions you app may ask.
You can find the list of those permissions here: https://play.google.com/about/privacy-security/personal-sensitive/
Even if you don’t need and ask those permissions, make sure you know what third parties you use in the app that might trigger this requirement (eg. AdMob).
You’ll need to add the URL to the Privacy Policy URL at Store Listing section. The link must be publicly accessible. Google will not host it for you.
A Terms of Service is not required, but it’s useful to add rules regarding user-generated content, unacceptable behaviour and so on. For example, it’s useful to add intellectual property clauses, ownership over your content and licenses over user-generated content clauses.
I'm working on applying a custom company security policy in my company's application.
I use the AdalJs library and I see that even if I apply the my Azure policy to the AD application, because of the silent renewing tokens, I'm not able to comply with the policy requirements.
Is there a parameter to set in AdalJs library to disable the Renewing Tokens?
If not, I'll be forced to modify the library, but it is not what I'd like to do.
Thank u in advance.
OaicStef
No, there is no such parameter we can disable token renewing. If you have a common scenario require this feature, I suggest that you submit the feedback from here.
And if it is not a common scenario, you may need to modify the source code. For example, you can modify the acquireToken function to remove the relative code about _renewToken and modify it based on your special requirement.
We're looking into using OpenAM to handle security for a web app that we've created. I'm wondering about the/a proper way to set up policies that can be parameterized by value. Specifically, we sell items by county. Each user purchases either a few counties or all counties. I know that we could create a role/group/realm for every county in the US, and assign users to the appropriate roles/groups/realms. But that's a lot of things to manage when we'll never have a user buy more than five. Is there a way I can define a rule or policy to say "allow if the resource's county is in the user's list of counties"?
It seems like this should be possible. But I've been looking through OpenAM documentation, and I can't see a place where it says how to do such a thing.
This should be possible by implementing a custom Policy Condition. In your condition you could check the accessed URL (the policy evaluation mode needs to be self though) and you should have also access to the user's session ID, which should allow you to determine if the given user has the necessary privileges to access the given resource.
The documentation is a little bit sparse about this, but should help in general:
http://openam.forgerock.org/openam-documentation/openam-doc-source/doc/dev-guide/index.html#chap-policy-spi