locked
Does vanilla Lightswitch authentication require users to have roles assigned to them for roles to be visible as a selectionin drop down? RRS feed

  • Question

  • Hi ,

    Hopefully this isn't a dumb question:

    I have an application where Roles are being used as an equivalent to teams that certain users can belong to. I use a RIA service to bring in and make visible the users, usersinroles and roles to Lightswitch. The application allows a person to create a request and before submitting it, allows them to choose which role(team) to assign the request to. The idea is that you should be able to come in as any validated user, even if you don't 'have a role' ( belong to a team), and yet see the list of roles(teams) that the request can be assigned to.

    In my application, the requests are  in many to one relationship with roles. IF I add a user and assign them to a team/role, then the list of roles shows up in in requests ( dropdown is populated). If I add user but not role assigned to them, nothing shows up in  the team assigned(role) dropdown for the service request. This seems to be the case both under Windows Authentication and Forms Authentication.

    Is there something in the vanilla requirements/features of Lightswitch security/authentication that requires all users to be assign to roles, for roles to populate in a dropdown? If there isn't then its programmer error on my part   :(   ;-)

    Thanks for any insights provided!

    Wednesday, September 4, 2013 4:40 PM

Answers

  • Ok , I finally got to the bottom of this.

    Its not the roles, its the permissions. I had for dev purposes all roles created allowing for security administration permission. So any role could see the drop down values.

    If I removed the permission for the security administration from the roles, then which role had it mattered. If you didn't have a role that had a  security administration permission you couldn't see it.

    In the security model this makes sense. Roles are created, roles have permissions attached, and users are attached to roles and therefore get permissions. Since roles are part of security administration, to see them at all requires being given that permission. The problem is of course for Silverlight client this opens up requirement for them to see the 'Administration' menu in Silverlight too- which for my purposes I don't want . Only the top administrator for the app has security administration access

    As Paul Van Bladel indicated above this seems to enforce use of roles for permissions only, not as an option for a drop down.

    On the surface it looks like I may have to create a new table for team, replicate most of the values in the roles table into it, and use it as the table connected to the service requests- so that  the rest of the security model can still work as it does and is supposed to.

    If any of you see any other way around this let me know.

    But I thank both of you for the correspondence on this- it has helped me resolve whats wrong and what might be the workaround

    • Marked as answer by lvsund Friday, September 6, 2013 1:00 AM
    Friday, September 6, 2013 1:00 AM

All replies

  • I don't think there's any requirement that all users be in a role before you can list roles... can you post a code snippet of what you're trying that isn't working?

    Also, a bit of an aside, but just looking at your scenario from the post above, why couldn't you simply use an intrinsic table for Teams instead of overloading the roles?

    Wednesday, September 4, 2013 7:10 PM
    Moderator
  • Indeed, you should use the roles as a container for permissions. If you use it for something else, you give up it's primary, well euh... "role".


    paul van bladel

    Wednesday, September 4, 2013 7:56 PM
  • Hi

    Thanks.

    I don't really have any significant code being kicked off for the entity or create screen- just normal stuff:

    Namespace LightSwitchApplication
    
        Public Class CreateNewServiceRequest
    
            Private Sub CreateNewServiceRequest_InitializeDataWorkspace(ByVal saveChangesTo As Global.System.Collections.Generic.List(Of Global.Microsoft.LightSwitch.IDataService))
                ' Write your code here.
                If Me.RequestID.HasValue Then
                    'If Me.ServiceRequestProperty.RequestorID.Length > 0 Then
                    '    Me.ServiceRequestProperty = Me.DataWorkspace.ApplicationData.ServiceRequests_Single(Me.ServiceRequestProperty.RequestorID)
                    'Else
                    Me.ServiceRequestProperty = Me.ServiceRequest
                Else
                    Me.ServiceRequestProperty = New ServiceRequest()
                End If
            End Sub
    
            Private Sub CreateNewServiceRequest_Saved()
                ' Write your code here.
                Me.Close(False)
                Application.Current.ShowDefaultScreen(Me.ServiceRequestProperty)
            End Sub
    
            Private Sub CreateNewServiceRequest_Created()
                ' Write your code here.
    
            End Sub
        End Class
    
    End Namespace

    I probably provided too little information with the original question :(

    The application uses roles,users in roles, and users because the application allows some users to be in roles and not others. For a service request- roles are used because these requests can be assigned to different teams who in turn only see the requests assigned to them as teams.

    Additionally, users in roles are used because once assigned to a team, the request is then assigned to person in a team.

    The only users that are special are  those assigned to teams ( to be in a position to see submitted requests). Any other user coming into the application is deemed to be someone who would submit a request, but does not require to be in any special role.

    Permissions are used to determine what the user sees when they come in. If they are admin, they see all menu drop downs and choices. If they are 'team' members, they see everything but the admin specific activities. If they are standard non team users - they only see end user choices.

    Below is a screenshot of screen layout:

    Team Assigned To is connected to RoleProxies Query- both left bottom and right bottom.

    If a person is on one team as team member, and you go to this page- all team names appear in dropdown

    IF a person is generic user with no team, no team names show up on the team assigned to dropdown

    Bottom line nothing complicated going on here with respect to any special coding that would specifically tie user to role in the screen.

    Having said that- user in role is tied into service requests but only on a 0-1 to many - meaning that a service request can have a user in role but doesn't have to. Service request must have a role however.

    Don't know if the above or below help ...

    Worst case scenario would be users all would need to be assigned to a requestappuser role that does nothing other than let them see these roles

    Wednesday, September 4, 2013 8:32 PM
  • Thanks

    I didn't provide enough info on the app - sorry

    Yes permissions are used  to determine what menu choices. I have applicationadministration for setup tables, team administration for seeing team menu choices, administrator for security administration

    Wednesday, September 4, 2013 8:37 PM
  • Ok thanks for the detail, I'm guessing a bit based on this:

    >>IF a person is generic user with no team, no team names show up on the team assigned to dropdown

    Since you actually have some authZ happening I'm not sure a user with no role/perms would have perms to read everything in the security service...  I suspect that you need perms to read that table but would have guess it to be security admin perms which doesn't sound like what your seeing w.r.t. the other users.

    One thing to try would be to take one of those users and hit the securitydataservice.svc and see if you can get the roles through there...

    • Marked as answer by lvsund Wednesday, September 4, 2013 9:18 PM
    • Unmarked as answer by lvsund Friday, September 6, 2013 1:00 AM
    Wednesday, September 4, 2013 8:58 PM
    Moderator
  • Correct in terms of what it doesn't sound like- I think.

    You don't have to be an Admin Role to see the list of roles in the dropdown- any role belonged to will allow it. It is only when no roles have been assigned to user that the drop down contents are not visible.

    Will need to look into this further...

    will mark your response above as tentatively answered- and assume that something else is going  on in my coding for time being.

    If I find something further in my coding will add to this thread...

    Wednesday, September 4, 2013 9:18 PM
  • Okay - do let us know, I don't think this scenario was in the forefront so may very well have something to dig into...
    Wednesday, September 4, 2013 9:39 PM
    Moderator
  • Thanks Brian.

    My sense of the Use Case here is that there would be lots of situations where you do want authentication of users, but not necessarily to assign them to a role, but allow them to see on read only basis- existing roles so long as they have been authenticated as users with any form of LightSwitch acceptable authentication.

    My application has:

    1.Users who have no roles

    2.Users who have roles

    3.Filtering of entities based on roles

    3.Filtering of entities based on user as sender/submitter of request

    4.Filtering of entities based on user as recipient of request

    5.Assignment of user within role for request

    6.Situations where user is in 2 of 3 roles- where for filtering of requests they see only requests for the two roles they are assigned to, and yet see all 3 roles where roles are being used for team assignment dropdown.

    All of those work for any user assigned to any role. Its only when no role assigned at all that no choices show up in team assignment dropdown.

    That is what had gotten me into proposing the question- will go thru my code to make sure I am not inadvertently assigning this behavior somewhere- but I don't think I am.

    I am suspecting that something like this shouldn't be difficult to reproduce either. IF I a create another application separate from this one- something fairly simple- where roles are brought in in a dropdown list I should be able to confirm whether this is unique to this app- or something generic. I may have to do that ...

    Wednesday, September 4, 2013 10:47 PM
  • Hi Brian

    I was able to reproduce this on a separate simple application.

    Per the above I bring in roles, users, users in roles via a WCF RIA Service ( I think I used Matt Thallman's original suggested approach from a couple of years back).

    I brought that in as a data source, and created a simple intrinsic entity called requests that had ID, title and description and then I linked it up in relation to the roles- ie 1 role to many requests. No other coding of any kind- straight vanilla lightswitch functionality.

    If I sign in as the admin- ie userid used in admin  role- I see the role drop down populated. If I sign in as another user put in NO roles, I do not see the role drop down populated.

    So I 'think' that is the vanilla standard behavior in the scenario above.

    For my uses the work around will be any authenticated user who is not intended to be in any special role that has permissions, will need to be assigned to a role called 'requestor' as an example. No privileges other than being grouped together with all other requestors - so that they can see role drop down populated.

    Thursday, September 5, 2013 2:43 PM
  • Ok , I finally got to the bottom of this.

    Its not the roles, its the permissions. I had for dev purposes all roles created allowing for security administration permission. So any role could see the drop down values.

    If I removed the permission for the security administration from the roles, then which role had it mattered. If you didn't have a role that had a  security administration permission you couldn't see it.

    In the security model this makes sense. Roles are created, roles have permissions attached, and users are attached to roles and therefore get permissions. Since roles are part of security administration, to see them at all requires being given that permission. The problem is of course for Silverlight client this opens up requirement for them to see the 'Administration' menu in Silverlight too- which for my purposes I don't want . Only the top administrator for the app has security administration access

    As Paul Van Bladel indicated above this seems to enforce use of roles for permissions only, not as an option for a drop down.

    On the surface it looks like I may have to create a new table for team, replicate most of the values in the roles table into it, and use it as the table connected to the service requests- so that  the rest of the security model can still work as it does and is supposed to.

    If any of you see any other way around this let me know.

    But I thank both of you for the correspondence on this- it has helped me resolve whats wrong and what might be the workaround

    • Marked as answer by lvsund Friday, September 6, 2013 1:00 AM
    Friday, September 6, 2013 1:00 AM
  • Thanks for following up - I suspected it might be an issue w/ access to the security info, but a scenario we hadn't tested...  and I do like your approach of using a new "Team" entity as I suspect that will simplify the solution in other places.

    Friday, September 6, 2013 3:10 PM
    Moderator