I have an ADFS environment with a configured a second Claim Provider along side the default Active Directory Claim Provider.HomeRealm discovery is "disabled" because I have set my Web Application to only use the non-AD Claim Provider.The current claim rules are configured so that claims coming from the second Claim Provider are included in the Auth token issued to clients connecting to my Web Application.
Is it possible to configure the claim rules to have claim data coming from both Active Directory and the second Claim Provider be included in the Auth token?
For example: Google[mail] + ActiveDirectory[samAccountName] => Auth Token
Yes, it is possible. The key point is how to map "user" returned from the second Claim Provider trust's to an AD user. Usually the token must contain a claim which can be used to query a respective user in AD. The following link shows how to query more claims from AD for such a scenario:
https://blogs.msdn.microsoft.com/pinch-perfect/2015/09/14/querying-attributes-from-active-directory-using-adfs-with-a-3rd-party-identity-provider/
Related
I would like to login to Firebase from an ERP system.
i.e. once logged into the ERP system, that login can be used to access a Firestore db.
The Firebase docs describe a common case: "Add an additional identifier on a user".
Is it possible to use this common case to login to Firebase from the ERP system?
Control Access with Custom Claims and Security Rules
User roles can be defined for the following common cases:
Add an additional identifier on a user. For example, a Firebase user could map to a different UID in another system.
If you want to use the users from an existing authentication system to authenticate against Firebase, you'll need to implement a custom authentication provider.
With such a provider, you:
Sign the user in with your existing system in a trusted environment (e.g. on a server).
You then use the user's credentials to mint a custom JWT token.
Send that token back the client, which then finally
Uses the custom token to sign in to Firebase.
At this point, the user is signed in to Firebase Authentication in the client, and their UID (and other properties from their token) are available in the Firestore security rules.
I am setting up an instance of WSO2 API manager, and want to give developers access to the API "store" pages by linking it to my existing OpenID Connect identity server (OpenAM). I've added the OIDC configuration into the store configuration file (wso2am-2.6.0/repository/deployment/server/jaggeryapps/store/site/conf/site.json) with all the details of the authorise, token, userinfo endpoints, etc.
When users click login in the store, it is correctly redirecting them to OpenAM to login, and passing an access token back to the store app. I've also ensured some of the required claims are returned from the userinfo endpoint (like preferred_username). I'm also returning a "groups" claim listing the groups the user should be in "subscriber" for example.
The claims I'm returning from userinfo are:
{
"address":{
"formatted":"My House"
},
"given_name":"Danny",
"family_name":"Developer",
"name":"Danny Developer",
"preferred_username":"Danny Developer",
"groups":[
"subscriber"
],
"email":"adam.hatherly#nhs.net",
"sub":"developer1"
}
However, whatever I try with claims and group names, the store still gives the error message "User is not permitted to log in to the Store.". I assume there's something else I need to add in either the access token or userinfo endpoint
claims list to make the store app accept the user, or some other config in the store or carbon console?
The reason for the user login issue is that the user does not have relevant permissions to log in to the store. User needs to have internal/subscriber role assigned to it. Since the user is coming from OpenAM and APIM does not have any information to authorize it, login fails.
For this either you should share the user OpenAM user store with APIM (say a shared LDAP) and assign users with internal/subscriber role or use a custom code to add the user to the APIM user store and assign the role.
Another easiest option is to create a user in APIM side (add a dummy password) with subscriber role. but this is not a suitable solution if you do not know all the users
My system works as follows;
I have an ASP.Net RESTful API server, which contains a user database.
I also have a Xamarin.Forms application, with a registration and login page.
What I want is to have the ability to authenticate a login using a social IdP, and then, if that user has not been logged in before, register that user in my local database.
I have been reading up on how to implement OAuth 2.0 with OpenID Connect to authenticate my users with a social IdP, however, I cannot seem to wrap my head arround it. From what I've read, I shouldn't use an Access token for authentication, since that i what the ID token is for, however, I have also read that the only intended purpose for an ID token, is the client.
My problem then is, how can I make sure that calls made to my ASP.Net server, has been made by "real person", and how do I determine who makes the call?
Access token will be used determine whether the client application was authorized by a user to access a resource. The concept of ID token comes from OpenID Connect. Main purpose of the ID token is to authenticate the user to the client application (i.e. letting the client application know that the person who authorized the access is a valid person).
To do this, you have to validate the ID token. This can be done using third party libraries such as nimbusds or auth0. You can validate the signature of the token verify the integrity of the token and check the claims included in the token (by comparing them with expected values) to verify the user details. Also, you can add custom claims (any claim that is specific for your application/implementation) to the tokens through your identity provider so that you'll be able to validate those particular claims in order to verify the user.
I am trying to implement JWT authorization based on this article.
I also need to let specific users (admins) impersonate other users (clients).
I see two possibilities here:
make admin requests using the admin token and add the impersonated client_id to each of the request;
request a new token for the admin which will contain the username and roles of the CLIENT in its payload, so it will basically become a client token, but it will also have two extra fields: "impersonated=true" and "impersonator_admin_id=x".
I would prefer the second one as it would be easier to use the .net built-in authorization attribute with the clients roles.
But I'm not sure if this opens up security holes or if it can be actually implemented using .Net's OAuthAuthorizationServer.
From your links, first decide if the admin is impersonating an user or acting on behalf of. Note that on-behalf-of != impersonation
A acts on behalf of B when A maintain its own identity and is given all rights from B
A impersonates B when for all intents and purposes A is B
In JWT RFC is not defined any specific claim for this purpose. In this draft the author proposes to include an on-behalf-of claim obo
{"obo": {
"prn":"mailto:joe#example.com",
"ctx":["urn:adatum.com:calendar"]
}}
prn identifies the principal for whom the bearer of the JWT is acting on behalf of.
ctx stablish permission contexts in which the bearer is allowed to act on behalf of the principal. This claim should by mandatory to restrict the contexts in which the delegated rights are to be exercised
Note that the obo claims are not included in IANA's JSON Web Token Claims, so they should be taken as a recommendation. There is a similar claim azp in OpenID but it is not clear how to apply it
azp : Authorized party - the party to which the ID Token was issued
Answering your question, in the first case I think you are talking about acting on-behalf-of, so include the client_id and the security context. The second case would be impersonation.
Impersonation always comes with serious security implications as it allows "to become someone else".
For that reason, you would need to make sure to make this state as visible as possible by e.g. introducing intensive audit logging. Also (to distinguish between real logins and impersonation logins) you would want to be able to transfer information about this very special state within your JWT access tokens by e.g. adding additional impersonated and impersonator properties to the profile of the impersonated user (as you described in your second point).
In the end you would probably end up having an regular API endpoint excepting requests like this ...
POST https://YOUR_DOMAIN/users/{user_id}/impersonate
Content-Type: 'application/json'
Authorization: 'Bearer {ACCESS_TOKEN}'
{
impersonator_id: "IMPERSONATOR_ID"
}
... which would hand out specific impersonation tokens that would allow to use service "through the users eyes".
I'm developing a basic messaging app with Firebase's built-in email/password authentication system. I'd like to add a key value "username" option to the resultant authData payload as a message author identifier that's not the user's email address.
I've read the official documentation front to back and from all accounts, the idea is to migrate over to a custom token authentication system if you're adding custom data to the authData, but i'd really like to keep the existing auth system as is, unless I can continue to use the same auth information already resident in Firebase but just with a new custom token auth login.
Thanks.
You cannot add custom attributes to the authData (or the auth variable in security rules) for the built-in email+password or OAuth providers. The common way around this limitation is as Jay commented to store the additional user data in your Firebase database under a /users/$uid node.
The only identity provider where you have control over the authData is when you use custom authentication.