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
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.
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 using auth0 for authentication. I want to fetch all users including their roles. I generated token in auth0 and when I try to execute it in Postman or fiddler tool, Sometimes it's giving roles and sometimes not. Same thing is happening in application also.
If I add manually in app metadata in role property as below, Then information is coming.
{
"authorization": {
"groups": [
"Admins",
"Users"
],
"roles": [
"Admin"
],
"permissions": []
}
}
But I fill, that if I change in authorization tab, It should effect here also.
Below is my code,
var apiUser = new ManagementApiClient("<<Token>>", new Uri("https://<<Domain>>/api/v2"));
IPagedList<User> allUsers = await apiUser.Users.GetAllAsync();
Do I need to clear cache in auth0, If yes then how?
Based on the information you provided it seems that you're using the Auth0 Authorization extension to configure user role information.
If this is the case you should notice that the extension logic is run at login time by the means of a rule. When you have that extension installed you should also have a companion rule; in my account the rule is named auth0-authz and should be the same for your case assuming version 2.0 of the extension.
The impact of this is that the roles are surfaced at the user level at login time, so any changes to the configured roles will be seen next time the user logins.
Note: Since this logic is part of a rule it will only be executed in the context of a login. If users are added to or removed from a group this will only be reflected within Auth0 after this user logs in again (eg: in the user's app_metadata or when calling the /userinfo endpoint).
You're querying the users directly through Auth0 Management API which may lead to the situation where the roles currently stored at the user profile are not up-to-date. If you are seeing stale information then this might be the cause.
On the other hand if your problem is not exactly this one, please provide further information and if possible steps to reproduce. For example, do the roles information show for one user but not the other or does it show for user A in one response, but then if you make another request the response does not include role information for that same user A?
I was not using the authorisation extension, but rather the standard role. So I've had to create the below rule.
More info here : http://isbyr.com/return-user-roles-in-auth0/
function (user, context, callback) {
// Get the user roles from the Authorization context
const assignedRoles = (context.authorization || {}).roles;
// Update the user object.
user.rolez = assignedRoles;
callback(null, user, context);```
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/
I'm developing an ASP.NET MVC application. I need to support multiple authentication mechanisms (this app is used by multiple customers, each with their own preferred authn provider). One auth provider will be Active Directory. The AD integration for authentication is straightforward and I have no problems with that.
For authorization, roles will be stored in a local database (NOTE: we cannot use Active Directory groups for doing authorization - roles need to be local application roles because we support multiple authn providers and AD admins won't want to create custom groups in AD just for our app). My expectation is that we will need to create "stub" user accounts in our local database in order to do the User-is-assigned-which-Roles mapping. These stub user accounts will also be used to indicate which users are authorized to access the application (not everyone in the AD database should have access).
The anticipated flow of control will be:
User accesses login page > enters credentials > posts credentials to app server.
The app validates the credentials against AD. At this point, we know if the user is authenticated.
The app checks the user's SID to see if a "stub" user account with that SID exists in the local database. If not, the app displays an "not authorized" error message to the user.
The app will look up roles for the user in the local database user-is-assigned-which-roles table.
User identity info including roles will be stored as claims and the app will use typical claims based authorization (i.e. ClaimsAuthorizationManager).
My question is what is the best way to create "stub" user accounts into my local database? My guess is that we should use some sort of AD export script to export AD accounts for those users that should be granted access to the ASP.NET app and then import those users into the local database (NOTE: I expect that the stub account will contain minimal info - perhaps just the user's SID from AD and maybe the username).
A batch export/import is probably OK as an initial deployment process. After the app is up-and-running and new users join the organization, I expect a more user-friendly mechanism will be desired for granting a new user access to our app (other than exporting/importing the new user's account from AD to our local database). My guess is that we'll need some sort of user browser screen so that an admin in our app can browse the AD directory, select a user, click a button and then have that user's "stub" account created automatically in our app.
Has anyone implemented an application with similar requirements? If so, how did you bootstrap the creation of "stub" accounts in your local database? Is there a better way to address these requirements?
Please feel free if this can Help You Custom Annotation Authorization
It's only a workaround, or just an idea, not a solution...
To use it you only need to use Annotation in the controller
e.g.
[ARQAuthorize]
public class BlaBlaController : Controller .....
I am currently implementing a similar solution. Here is how the application works. I'm using ASP.NET MVC 5, ASP.NET Identity 2.2.1.
I am using the Identity framework to manage users and roles within the application. The user goes to a login page, enters their credentials. The application checks against the application DB to see if the user exists. If not it throws an error that the user doesn't exist in the database. If the user exists, it authenticates against AD. If authentication fails they get an error message, if it doesn't fail I create a ClaimIdentity from the user out of the database (not the user in AD) and pass that to my SignIn method.
My user in the application DB has the same username as the AD username and I use that as my stub. I also include the domain of the user in the DB as well in the case that I might have multiple domains I need to support. With Identity, don't forget to also populate the SecurityStamp field with a guid.
The plan is to bulk import the users and permissions from a spreadsheet and I have some standard CRUD actions created to allow creation of individual users and assigning of roles after that.