OK, so it's a badly phrased question. But it's hard to explain in a single line.
I've tried to read the Shibboleth documentation and being a newbie got out of my depth fairly rapidly. I don't really want to spend days understanding it if an expert can take half a minute to say "no chance, that won't work".
I have many groups of users, lets say (for now) that groups are different companies.
What I'd like to do is only allow users to see some fields from other companies.
For example I'm Alice in Company A and I can see that Bob in Company B has an email address bob#b.com. He can see that I'm alice#a.com
However everyone else in Company B can see that Bob has a last name and a phone number etc.
And everyone else in Company A can see my details.
To make this more complicated, lets say that Bob and I become friends and decide we want to share our information then we create a "transient" group "alice&bob". Because we are both members of that group, we can both see each others full details. (But nobody else in A can see Bob's details unless they are also friends and vice versa)
I can sort all that out in application code by querying all attributes and relationships and only showing what's relevant but for extra security I'd like to limit the disclosure of information at source.
I think I need to use attribute filters but not sure if they are able to give me this level of control. With this flexibility of being able to form relationships, will I need to build filter files on the fly and then end up with thousands of filters that Shibboleth starts to choke on because the logic is so long.
Something like the "is requester in group" filter rule :
https://wiki.shibboleth.net/confluence/display/SHIB2/IdPFilterRequirementAttributeRequesterInEntityGroup
The answer above is quite good, but i believe that non shibboleth users will find it confusing.
The quick answer is You really don't want to do it this way, it may be possible to do but for 100% there are better tools to do it.
Ok, full version now (sorry for being too obvious i some places).
In shibboleth architecture we can distinguish two main components.
Identity Provider IdP- which holds information about users from specific organizations.
Service Provider SP - which are generally some service or protected resource, for which we can define some access rules
In your example credentials for Alice and Bob could be stored in different IdP, because they are member of different organizations/companies, or (which isn't exactly matching the whole pattern) you can have one IdP for all users, and "company" is just one of user attributes. IdP doesn't provide you any kind of api that will give you opportunity to access users attributes for any user, apart from the one that is being authenticated.
On the other hand you have your SP, which hold some super secret resources, for which you can define policies. And in which you would like to define polices for user information.
And here lays the problem, on SP side you don't have access to whole users database, that's the way Shibboleth works. You can of course treat all users information as a resource in your SP, but why in the hell would you like to use Shibboleth if you have clear access to all users credentials on you application side?
If you store all users information on you service side I believe that any well designed relational database with some kind of authentication for your service will be better than shibboleth for this job.
Hope that helped.
This is not a job for Shibboleth or for most SAML/SSO providers, for that matter. The attribute filtering you speak of is used for filtering those attributes between the IdP and SP ... which is basically saying : let service provider or "application" B see the following attributes from IdP A.
Once you transmit the attributes to the SP on the other end, Shibboleth does not (and indeed cannot) provide you with a mechanism to prevent users of application B from seeing any data that you present to them ... in fact, they really shouldnt be able to see any data transmitted by the IdP unless you are exposing it in someway via your application.
Related
I am currently setting up a small server with several applications. Since no Active Directory etc is planned, but I do need a centralized user administration, I decided for LDAP since all applications are capable of authenticating against it.
I have already set up a domain "dc=example,dc=lan". It has two organizational Units. Groups and Users. My plan was, to create a posixGroup for every application, so that a user can be added to each group (if he/she was allowed to use this application).
The structure would then be (example):
for each group
cn=ejabberd,ou=groups,dc=example,dc=lan
where cn=ejabberd is of type "posixGroup"
and for users
cn=user1,ou=users,dc=example,dc=lan
where cn=user1 is of type "posixAccount"
Some, but not all, applications expect the "mail" attribute as login name. Some don't.
My problem is, that searching for users in ou=users is easy as 1,2,3 - searching in "cn=ejabberd,ou=groups,dc=example,dc=lan" is sheer driving me crazy since the users are not a "child" to this group but a "memberuid" attribute.
I have tried different filters and thought about another setup.. Just cannot think of anything different making sense right now.
Am I running down the wrong way, or maybe just blind to what's right in front of me?
I'd be glad for any finger pointing out a direction.
So here is, how I did it:
I created the following structure.
+dc=example,dc=com
+ou=groups
| +employees (PosixGroup)
| +service1 (GroupOfNames)
| +service2 (GroupOfNames)
+ou=users
| +user1 (User Account)
| +user2 (User Account)
etc..
Groups like "service1" and "service2" are of type "GroupOfNames". Furthermore I had to install the "memberOf"-Overlay so I could search for this exact attribute of a user.
This now gives me the possibility to tell each service to use a search filter that returns only the members of one special group, which will be granted access. For instance, ejabberd will use this filter:
"(&(objectClass=inetOrgPerson)(memberof=cn=ejabberd,ou=groups,dc=example,dc=com))"
Found these informations on the following website. Just take care to set the filter case sensitive! "memberOf" will not return any results, since the overlay in this example uses "memberof".
http://www.schenkels.nl/2013/03/how-to-setup-openldap-with-memberof-overlay-ubuntu-12-04/
I suggest you're on the wrong track. You don't want to authenticate by application, you just want to define overall roles that users can be in. The applications can then be defined to require certain role(s) per application funtion, web page, etc. As a limiting case, an application can be a role, but if you set out to define it that way you're overly limiting yourself.
To answer your immediate problem, you only have to search under the ou=Groups item for posixGroups which have memberUID={0} where {0} is the DN of the user. In other words the search filter is
(&(objectClass=posixGroup)(memberUID={0}))
Iterating those search results then gives you the DNs of all the groups of which he is a member.
I'm trying to design MVC4.5 website on Azure with latest EF but stuck in setting up membership and role base authentication.
I'm somewhat lost in MembershipProvider, SimpleMembershipProvider and ExtendedMembershipProvider.
I found that unlike SqlMembershipProvider the SimplememberShipProvider is not designed to store multiple applications (through ApplicationName and ApplicationID) in a single database and map users accordingly so that business can run multiple applications with only one database.
I hear all praises of SimpleMembershipProvider, my question is how should the database/providers be designed so that I'm able to store user's in association with respective applications in a single database. User registration info must be completely independent from same user name in other application. I also need new features of Open Authentication.
Broadly, my queries are:
Is it possible to use SimpleMmebershipProvider to differentiate between multiple applications in a single database.
I'm thinking to modify existing schema structure made by SimpleMembershipProvider to include ApplicationId column , but then how would even a custom provider that is inherited from Extended membership provider add ApplicationId against any user.
Is there any other provider available or any article that would guide in implementing custom membership provider with custom database design along with features of open authentication.
Or am I going with completely wrong approach?
Answering to the queries of BernardG
Do you want a "head" url/site, then redirect users to the proper
application, or
No, sites should not appear related nor will be redirect to other.
Do you want a user to enter into any application and
then be redirected to another one he is registered in.
Again no, each application should have it's own registration process. Further two applications can have same username but these accounts would not be related.
Can a user register into any application?
Yes.
If not, how do you limit that?
Not limiting.
What do you mean by this?"User registration info must be completely
independent from same user name in other application."
Refering to answer to point 2, if there are 4 applications with one database and a user registers for one application, he must need to register again to have access to other application. Hence for any user the sites must not appear related.
Do you want to duplicate users info into each applications?
As per my understanding of the question a combination of username and email address (considering this combination makes any user account unique) can again be stored against another application even with different profile information.
Actually I'm used to the classic membership approach used in ASP.net 2.0 and I'm missing the application Id column for separation.
If I may, I believe your question has a lot more to do with design and establishing clearly the features you want, rather than a specific membership provider, knowing that you can do about anything you want with SimpleMembership.
My questions, and I believe those are the questions you have to ask yourself before going further, are:
Do you want a "head" url/site, then redirect users to the proper
application, or
Do you want a user to enter into any application and
then be redirected to another one he is registered in.
Can a user register into any application?
If not, how do you limit that?
What do you mean by this?"User registration info must be completely
independent from same user name in other application."
Do you want to duplicate users info into each applications?
It looks to me that this is all about database(s) design, and analysis, for your real needs. Once that's properly done, the part about membership tables will be easily solved.
Not sure if I'm going about this the "right" way.
In my application, I have recently had the requirement added for a second "type" of user. This means realistically I will need to route this user to a different controller than the primary type.
As a more concrete example:
The primary user of the application will be staff members. They will need to see company wide information.
Now, clients of the company will need to be able to log into the application, and see information specific to their needs (and no more).
Furthermore, there are likely to be more types of user in the future.
What is the "correct" way of designing/implementing this?
I think that, if you control the users role in the TWIG templates and showing them the only links that they could access (and, of course, protecting the routes with firewalls in the security.yml) may work.
We are implementing federated identity management and have a scenario where users need to authenticate against uniquely identified items. For instance Bob might have read access to records 12345, 34444, 23443 and 23443 while Jane might have read/write access to records 12345, 34444, and 23443 and read access to record 56445.
I have two questions:
Let's say someone has access to a hundred or a thousand separate and unique records. With claims based security I understand the incoming security token would contain all these claims. Is the size of the token going to be a problem?
I don't see a lot of guidance on creating a management system for administering the authorizations, i.e. in our case assigning users to the authenticated records. I see a lot of advice about making the authorizations declarative whereever possible, but not a lot about what to do when that's not possible.
Any advice or direction is much appreciated.
On #1: yes, you can potentially end up with a very large token if you are modeling entitlements as claims (e.g. a claim for each record a user has access to). If you have 100,000 records, then you can potentially end up with 100,000 claims.
The "granularity" of claims is one of those "it depends" topics. In general, the recommendation is to keep claims "coarse" (e.g. groups, roles, organizations, etc) and then associate those with fine grained permissions in the app (which can still be implemented declaratively).
Also, I would suggest you ask the question: "who is an authority on the information that will be conveyed in a token?" If the knowledge that "user x is entitled to read record 23455 and 2456" is application specific, then it belongs in the app, not the STS.
My requirement is the claims assigned to a user are company aware so say for example
User 1: is publisher for Product Manager for Company 1 but the same user is only editor for Company B. Can this be achieved through Geneva Server, or additional code needs to be written to override classes.
In my opinion it's the relying party itself should be making decisions on what roles to attach to a token based upon the identity itself.
However you can set rules based on individual relying parties and choose to serve information as a claim based on whatever the backing store says. Now how you represent that information in whatever backing store you are using (AD, LDAP, SQL, whatever) is a design decision at your end. You may also want to look at harnessing the claims transformation language in beta 2.
It's really hard to give any specific advice without knowing details about where your claim backing store is going to be and why you think you need to go this route.