Azure ACS and storing information for users on it vs local?

时间秒杀一切 提交于 2020-01-01 06:44:12

问题


I'm working with Azure ACS and incorporating it into an SSO strategy for my .NET 4.0 website. I see on the Rule Groups page that a bunch of different claims can be stored and passed back to the RP (e.g. country, streetaddress, phone, etc.). It looks like you can also return back any claim type you want to create. This got me thinking about many questions relating to storing information for users:

  • Does it make sense to store user information (other than the nameidentifier) in ACS vs local database tables?
  • It sounded like you could make unlimited rule groups and rules inside of them. Is that correct?
  • I would be dealing with different companies and users inside the company. Would creating a rule group for each company and then making rules for each user be a wise choice?
  • It appears that the API is pretty robust and would enable this to be done automatically as a result of a sign up page, etc. Correct or incorrect?
  • Would it be feasible and recommended to run a query against ACS to return information back about a user (e.g. query for their email address when they're offline to send them a message about something)
  • Could you grab bulk information for reporting purposes off of ACS?

回答1:


The short answer is generally "yes", but of course there's a longer answer :-).

Does it make sense to store user information (other than the nameidentifier) in ACS vs local database tables? Yes it could make sense. But for optimization purposes you might keep a copy of some of the user profile information somewhere else (local to the app). ACS rules information would be the "master record" you would update the values in your local store whenever you get a token and check whether there've been changes or not.

It sounded like you could make unlimited rule groups and rules inside of them. Is that correct? No, "unlimited" is a big number. There are limits in the number of namespaces, relying parties and rules. Check the documentation. ACS also supports "cascading" transformations, which can help you reduce the number of rules.

For example:

  • email: eugeniop@mail.com -> company:Contoso
  • Company: Contoso -> Language: English

The 2nd rule will be triggered whenever a claim of type "Company", value "Contoso" is issued.

Then you can have:

  • email: rob@othermail.com -> company: Contoso

The "language" claim will be automatically added.

I would be dealing with different companies and users inside the company. Would creating a rule group for each company and then making rules for each user be a wise choice? In a multi-tenant environment, it might be better to have a Relying Party per tenant. This is what we do in sample 7 (Federation With Multiple Partners) available here: http://claimsid.codeplex.com

It appears that the API is pretty robust and would enable this to be done automatically as a result of a sign up page, etc. Correct or incorrect? Yes

Would it be feasible and recommended to run a query against ACS to return information back about a user (e.g. query for their email address when they're offline to send them a message about something) It is possible. However, there's no concept of "user" in ACS. So yuou would have to decode that from the rules. You can't have a call like "GetUserprofile( string user)"

Could you grab bulk information for reporting purposes off of ACS? The API supports bulk info, but for reporting it might be better to have replicated information on your own database.

One last thought: ACS rules engine today is very simple and only does simple transformations (plus cascading), but nothing compared to what ADFS can do today, where rules can be really complex (e.g. db lookups, etc)



来源:https://stackoverflow.com/questions/6061060/azure-acs-and-storing-information-for-users-on-it-vs-local

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!