Maybe I didn't really get the concept but basicly if you say you're compatible with SCIM then there must be certain expectations of properties that belong to identities am I right?
For an example if you take a look at the example createUser request from
https://developers.onelogin.com/scim/implement-scim-api
you will see a variety of different properties like displayName, nickName etc..
My use case however requires only one name, the userName.
My question is, are any of these even required to say that you are SCIM compliant?
The RFC7643 indicates that the id parameter must be included.
The requirement for the other properties depends on the resource type and thus schemas used by your application. For a user resource, the section 4.1 of the RFC indicates that the userName is also required.
Related
I'm trying to get the user's identity from an adapter and I see that the documentation mentions two different APIs that look like having equivalent descriptions to me: getActiveUser and getCurrentUserIdentity.
Looks like the first one needs a realm as a parameter: https://stackoverflow.com/a/17018349/239408. I don't know about the other one.
The documentation also refers to a strong identity concept that I haven't seen described anywhere.
Should I prefer one method over another? When should I expect to have a "strong identity" and not get back a null?
When you have multiple realms, each one of them will have a userId. e.g. realm used for authenticating users will have userIdentity that describes user properties, i.e. username, date of birth, displayName. realm used for authenticating devices will have userIdentity describing device properties, i.e. deviceId, platform, OS version etc.
getActiveUser(realm) will get you a userIdentity of the specified realm. if you do getActiveUser("wl_deviceNoProvisioningRealm") you'll get identity of the device (assuming you are using wl_deviceNoProvisioningRealm).
getCurrentUserIdentity() and getCurrentDeviceIdentity() APIs are built on top of getActiveUser(). You don't have to specify explicitly which realm is used to identify user and which realm is used to identify device, WL server will do this for you and you'll automatically get userIdentity of current user and userIdentity of current device.
I'm reading the shiro documentation and never found any signs that shiro supports user groups concept on API level.
I would have expected that Subject.java would have such methods as getUserGroups, but it doesn't. For example, if I write some application which aims to work with numerous authentication systems, when the user creates some object, I would like to make it visible for all users in the object creator's groups, and to do it in an authentication provider agnostic way, using some facade API, like shiro Subject.
But it's looks like I can't doing this using shiro api, is this correct?
How do you support user groups concept in multi-auth applications ?
Should I write some UserGroupAwareSubject extension ?
Shiro as of 1.2 does not have a Group concept in its API - it has the notion of Roles and Permissions.
This is not a problem if you have only Roles or you can use your Group names as what Shiro calls Roles (i.e. realm.hasRole(roleIdentifier, authzInfo) uses your Group name as the 'roleIdentifier').
If you have both Role and Group concepts in your application, you will probably not easily be able to use subject.hasRole for checking both. If you'd like this as a feature, please open a feature request.
Two options for this though if you want to make it work is:
Have one Realm where realm.hasRole calls check against your Roles and another Realm where realm.hasRole calls checks against your Groups.
Use one Realm to perform both and just prefix the strings you use for group checks with a recognizable token, e.g.:
subject.hasRole("group:myGroupName");
Then your realm can check to see if has that prefix, and if so, do a group check, and if not, do a role check.
These options aside, what many people do in this case is ignore Role and Group checks entirely and instead rely on (the more powerful) permission checks in code:
subject.isPermitted("document:1234:read");
Then your Realm can check both the Subject and any of its assigned Groups or Roles to see if they imply that permission. If so, then you don't need any Group or Role checks at all because your code relies on permissions instead of the (potentially volatile and numerous) Groups/Roles concept.
There are some good reasons why permissions are probably better than Role or Group checks, but if you feel otherwise and would still like Groups represented in the Subject API any, please do open a feature request.
Regards,
Les
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.
We are currently looking into implementing our own STS (Microsoft WIF) for authenticating our users, and in that process we have come up with a few questions that we haven’t been able to answer.
We have different kinds of users, using different kinds of applications. Each kind of user needs some special types of claims only relevant for that kind of users and the application belonging.
Note that we do not control all the clients.
Let’s say that all users are authorized using simple https using username and password (.NET MVC3). A user is uniquely identified by its type, username and password (not username and password alone). So I will need to create an endpoint for each user type, to be able to differentiate between them. When a user authorize, I’ll issue a token containing a claim representing the user type. Is there an easier way for doing this? Can I avoid an endpoint for each user type (currently there are three)?
My token service can then examine the authorized users’ token and transform the claims, issuing a token containing all the users’ type specific claims. So far so good, except for the multiple endpoints I think?
If I need to have multiple endpoints, should I expose different metadata documents as well, one for each endpoint? Having one big metadata document containing a description of all claims, doesn’t make any sense since there is no application that needs all claims.
Update
Some clarifications.
Certain applications are only used by certain types of users. Not one application can be used by multiple user types.
Depending on what type of application the request is coming from, username and passwords needs to be compared for that user type. There are user stores for each type of application. That is why I need to know what application type the request is coming from. I can't resolve the type by the username and password alone.
Based on your problem description, it sounds like you have three indepent user "repositories" (one for each user type).
So imho this would be a valid scenario for three STS or a STS with multiple endpoints.
Another way to solve this could be to distinguish the user type by the indentifier of the replying party redirecting the user to the sts. This identifier is submitted in the wtrealm parameter.
The processing sequence could look like the following:
Get configuration for relying party (wtrealm) from configuration store (I'd suggest a database for your rather complex case)
Validate user with username, password and user type (from relying party configuration)
Add claims depending on user type or relying party specific configuration.
The datasbase/class structure for this could look similiar to this:
Need some more information to answer:
Are certain applications only used by certain types of users? Or can any user type access any application? If the former, you can configure the STS for that application to pass that user type as a claim. Each application can be configured to have its own subset of claims.
Where is the user type derived from? If from a repository, could you not simply construct a claim for it?
Update:
#Peter's solution should work.
Wrt. the 3 STS vs. 3 endpoints,
Many STS - can use same standard endpoint with different "code-behind". Would still work if you migrated to an out-the box solution . Extra work for certificate renewals.
One STS - custom endpoints won't be able to be migrated. Only one STS to update for certificate renewals.
Metadata - given that it can be generated dynamically, doesn't really matter. Refer Generating Federation Metadata Dynamically.
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.