I would like to use the name of the relying party in my Claim Rules. Does anyone know if and how I can get that?
(use case is: send out this data for ClaimX if the RP-Name is 'xxx', send out that data for ClaimX if the RP-Name is 'yyy')
I'm somewhat confused by this.
I assume you are talking about claims rules for a Claims Provider?
Each Relying Party has its own set of claims rules so RP xxx has its rules which can be completely different to the claims rules for RP yyy.
For the CP, there is a one-to-one relationship between a CP and its associated RP. So every CP "knows" which RP they are connected to.
Each CP has its own set of claims rules for its associated RP so the CP for RP xxx can have rules which can be completely different to the claims rules for the CP associated with RP yyy.
What scenario are you talking about? Can you expand on this please?
Related
I need some help in understanding a basic thing or two with Token-based authentication.
My setup is a backend asp.net core app with openiddict for token auth. It's all working well so far - I now need to add user-permissions. I will have a lot of them (e.g. User can view xy, user can edit xy, user can delete xy, with many different xy-components). Backend is working well so far, my problem is now: How to get these permissions via token to my client side app..
As far as I understood these are not classical "claims" as a claim would describe "who" you are rather "what you are allowed to do" . Right?
But how can I pack them into my id_token/ How can I add them to my payload?
Second thing: Do I need to validate the token (signature) in my case? Every Api-request ist validated at server side, so basically I don't need to care if my client side permissions are tempered with, right? (As they are only for UI-Display purposes)
Thanks for your help!
As far as I understood these are not classical "claims" as a claim would describe "who" you are rather "what you are allowed to do" . Right?
In theory, nothing prevents you from representing permissions as claims, just like you'd do with roles or any other claim. In practice tho', it's rarely the best approach, because the number of actions a user can do is usually important (and often unlimited: can the user A update the product 124? And this other product?).
A possible alternative is to catch the 403 responses returned by your API when a user is not allowed to execute a specific action so you can display an adequate error message. Another one is to create an API endpoint that dynamically determines whether a user is allowed to execute the action, according to your own policy.
Second thing: Do I need to validate the token (signature) in my case? Every Api-request ist validated at server side, so basically I don't need to care if my client side permissions are tempered with, right? (As they are only for UI-Display purposes)
Both access tokens and identity tokens are digitally signed, so they can't be tempered with (at least, not easily). You don't need to validate signatures yourself, as it's already done by the validation/JWT middleware.
I have a question about RESTful APIs and security in a multi-tenant environment.
Imagine you have an endpoint: api/branches/:branchId/accounts/:accountId
Authentication is done through Bearer Tokens (oauth2). Each token includes a set of claims associated to the invoking user. A branchId claim is included in the token, and each user belongs to a single branch.
The security restrictions are the following:
The branchId of the GET request should match the one stored on the token claim.
accountId should be a valid account inside the branch identified by branchId.
The question is: which of the following solutions is correct?
Maintain the endpoint: api/branches/:branchId/accounts/:accountId. And do the required security checks.
Change the endpoint to: api/accounts/:accountId, obtain the branchId from the token, and then do the remaining security checks.
The application is meant to be multi-tenant. Each branch is a tenant, and each user may only access the information associated with its single branch.
Thanks!
I needed to make a decision fast, so I will be using solution 1. If anybody has an argument against or in favor please join the conversation.
Arguments in favor:
I totally agree with this answer: https://stackoverflow.com/a/13764490/2795999, using the full URL allows you to more efficiently decide which data store to connect with, and distribute load accordingly.
In addition you can easily implement caching, and logging because the full url is descriptive enough.
Independency of security and API. Today I am using OAuth2 but perhaps tomorrow I can send the request signature, and because the URL has all the information to fulfill the request it will work.
Arguments against:
Information redundancy: the branchId is on the URL and encrypted on the token.
A little more effort to implement.
I'm using Thinktecture Identity Server for SSO with some apps. The idea is that account information will be stored on the server in the claims information. So groups user membership and other hierarchies can exist on the SSO server. Then when some one authenticates they would get their membership and rights passed down through claims.
My question is how can my authentication subscriber perform a user.memberOf(x) kind of lookup? I can't imagine that the whole permission hierarchy gets passed down in a users claims. I imagine that additional queries would be performed against the sign on server like LDAP. How does this work for Thinktecture? Would it be the same generally for other SSO servers? If so what's the patterns name?
A general pattern is that, yes, you pass all roles in claims. This causes issues if there is too many groups but if this is so then it could be that the role model should be revisited.
Switching to oauth2-style authorization solves the issue: you don't pass claims in roles but then the relying party queries roles with an extra call. The drawback is that if the STS is further feredated with yet another STS, such extra calls become tricky as the call would require another internal call which would possibly require yet another call etc. Passing roles in claims means that there is no need for this extra call.
Yet another idea is switching to a custom STS that would issue claim roles filtered depending on the relying party or other user attributes. This could work as usually a single RP is not interested in all roles but rather a subset that makes sense there. Your filter is then implemented at the custom STS side.
Well - IdSrv is a custom STS. You can issue claims per RP - check this article (especially the part about IClaimsRepository):
http://leastprivilege.com/2013/05/17/customizing-identityserver/
I need ADFS 2.0 to tell my relying party application when current user's password will expire. Basically, I need to extract all the data from AD, using ADFS claim rules, to repeat logic of this article: http://blogs.msdn.com/b/adpowershell/archive/2010/08/09/9970198.aspx
I can access user-level AD attribute "Pwd-Last-Set" without problems (other than changed value caching for around 20 minutes), but:
I can not access domain-level attributes (like Max-Pwd-Age) from claim rules. How can I do that?
I can not find appropriate attributes for some of the data, like DomainMode.
May be there is some ready solution to this problem, which my googling skills where too weak to find?
You can only access AD attributes that pertain to the logged-in user.
For this kind of thing, I would suggest writing a custom attribute store which returns the info. you require.
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.