I'm new here.
I am currently working on a Silverlight application (SL4) with Ria Services. I use the MVVM pattern. My question is, has anyone any experience or idea, whether it is possible to implement a role-based access control at the field level. Both sides should it be dynamic. Permissions of a role should be adapted for the fields.
Yes definitely.
Read this article, at section 'Defining Access and profile properties'.
I support field level access in my application.
fine-grained permissions; PrincipalPermission - roles seperate from permissions;
I had to create my own code access security attribute and a view to assign permissions to roles.
I discovered that permissions are hierarchical in nature.
CREATE TABLE [dbo].[Permission](
[id] [uniqueidentifier] NOT NULL,
[parent_id] [uniqueidentifier] NULL,
[applicationmodule_id] [uniqueidentifier] NULL,
[action] [nvarchar](255) NOT NULL,
SecurityModuleAccess -> UpdateUser -> ResetPassword
Something that may help in assigning permissions to roles #TreeListView
http://demos.telerik.com/silverlight/#TreeListView/FirstLook
Related
We are successfully using the openiddict support for external providers (in our pilot case Azure AD). See image for external provider claims in this example.
The external provider redirects to /Account/ExternalLoginCallback where the external provider claims are available, and the method ends with redirecting to connect/authorize (thats internally calls CreateTicket).
There we have no access longer to the external provider claims, that we simply would like to return to the calling application, e g "name" and "preferred_username".
Please guide us for this flow.
A work around could of course be to save all wanted information from claims in the database on our extended IdentityUser class and then retrieve the information later in the flow. But we want to avoid that, we see no meening to store the information we simply want to forward. Keep storage simple.
I want to implement Authorization in my Asp.Net Core project.
Here are the scenario.
1.Teacher Editor has permission to add student and course
2.Teacher Admin has permission to view student and course, but no edit permission
3.Student has permission to view course only.
Current, I check every request in different methods whether they have the permission. I am wondering whether there is any better way to control it in a center way.
I assume I could define a table which is used to identity who has which permission.
Any help would be appreciated.
Update:
Teacher has different level like level 1, leave 2. Different levels have different permissions. For the same method, I need to check user level and user admin or Editor.
I have an existing application with its own user table. I'd like to add phpBB 3.1 to the application, but the question is how to do this without moving all user functions to phpBB (via whole site integration) and without maintaining separate user tables for the same user set (creating users in phpBB automagically).
Is there a relatively easy way of pointing phpBB to an existing user table for forum logins?
For old versions, this wiki page helped me to implement an external provider.
In version 3.1, the directory phpBB/includes/auth/ has been moved to phpBB/phpbb/auth/provider and there is a new documentation chapter.
You could create your own provider by extending \phpbb\auth\provider\base and implementing the provider_interface.
Here is a good template to duplicate with you own table. This is the internal standard db provider.
To declare the new provider you will create, the good practice is to create an extension and inject your new one. As example, here is a github project. It declare an external provider for social Network. The provider must be added to services.yml like in all Symfony Project.
If you don't want to create an extension, (this is not a good practice) you could edit services_auth.yml file by adding your own provider :
services: #do not add this line
auth.provider.db2:
class: acme\demo\auth\provider\db2
arguments:
- '#dbal.conn'
tags:
- { name: auth.provider }
In the book "Agile web applications with Yii 1.1 and PHP5 the RBAC is implemented though authassignment and a bizrule. This should support the possibility of granting users with different roles in each project.
but whenever a user is assigned a role in a specific project a new record is added to the authassignment table with this role and that user. since there are 3 roles (owner, member, reader) this does not allow assigning the user to more than 3 projects and the user must be assigned different roles in these projects (otherwise integrity constraint will be violated).
Any ideas? Is this really a flaw in the RBAC implementation in the book?
thanks
This is probably more of a role for business rules than creating individual roles. For example, a user may be give a particular role that allows them to create and own a project and then a business rule would be used to ensure that only they can administer their project.
I need to create a some SAML 2.0 assertions, and I'm having trouble finding what the XML should really look like. Most of the documentation seems to be about using particular tools, not about the messages. I've got the schemas, with a plethora of possibilities, but I can't find an example of what the relevant messages actually look like in practice.
The business rule says: in order to create a shared identity, the user tells system A their username and password on system B. System A needs to communicate this info (along with some demographics) to system B. System B validates the information and passes back a unique identifier which can then be used to refer to this user.
Could someone give me an example of what SAML 2.0 assertions would look like to carry this information?
FWIW, I'm using C#, and need to pass the XML around in ways which preclude using a 3rd-party tool.
I'm not sure your use case is quite what SAML 2.0 does.
What you describe as your business rules actually looks like a use case for identity provisioning, not access management.
Standard SAML 2.0 use cases focus on one party asserting identity (the identity provider) and the other party (or parties) relying on those assertions (the service provider). Assertions carry what's called a name identifier, use of which is agreed ahead of time between the identity provider and the service provider.
These name identifiers can be pretty much anything, but they broadly fall into two categories: transient and persistent. A transient name identifier is only useful in the context of the current session (and essentially only says, "I know who this person is") and tends to be used to protect the identity of the principal while allowing privileged access of some type. A persistent identifier can either be opaque (in a similar way to how OpenID is used to access SO) where the asserting party can repeatedly verify a principle's identity without disclosing their identity while maintaining a dynamic but stable shared identifier between the asserting and relying parties or more substantial, such as an Active Directory UPN (which can be pre-agreed ahead of time).
When it comes to passwords, as you mention in your question, the service provider (relying party) never sees the users password. The service provider hands the user over to the identity provider with an authentication request. The identity provider sends the user back to the service provider with a response, which in the case of successful authentication contains an assertion about the identity of the user in the context of the relationship between the identity provider and the service provider.
In context of your question, the big thing is that SAML 2.0 does not provide a way to either create the local "application" user account or link that local user account to a federated identity. This is simply not the problem SAML 2.0 tries to solve.
Now, back to your business rules...
It looks to me like what you're trying to do is either account linking or registration - I would approach it like this:
User visits application, clicks a button to use identity from the identity provider
The application produces an authentication request and directs the user to the identity provider, carrying that authentication request
The identity provider either logs in the user or reuses an existing identity session if the user has one. The IdP produces a response message containing an assertion about the user. In your case this assertion should at minimum carry a persistent name identifier. The identity provider directs the user back to the application, carrying the response message.
The application processes the response message. If a mapping entry exists for the persistent identifier passed the user is recognised from that mapping and logged in as that local application user. If no mapping entry exists the user can be asked to locally log in, and on successful local login the mapping entry can be produced, or a user account could be automatically created and the user could be asked to enter additional information (names, email addresses, etc.) The "corporate" use case would be that no automatic account linking or creation is allowed and that the mapping must exist ahead of time.
As for the content of the messages...
The OASIS Security Services Technical Committee has a zip file download available with extensive documentation of the parts of the XML schema, including examples. It's also well worthwhile reading the protocol and profile documentation, as these describe the flow of messages between the parties involved in the identity conversation.
There are a large number of presentations floating around that I found very useful. Specifically, SAML v2.0 Basics by Eve Maler helped me start realising what problems SAML v2.0 was trying to solve. This presentation includes examples of that assertions look like. There is an updated presentation and links to additional resources on saml.xml.org.
I'm not sure if any of this is going to help though, as your use case does not seem to be what SAML 2.0 is trying to do. You can add attributes and extensions as needed to requests and responses, but I can't see many identity providers doing anything with those attributes and responses.