I'm using HTMLFormIDP adapter in PingFederate IDP side. Each organization has their own adapter and login and logoff templates.
What would be the maximum number of adapters that can be created in PingFederate IDP?
There is no known limit for the number of adapters PingFederate can support.
Note that if you're only changing login and logoff template values in each instance, we'd recommend you create a hierarchy of adapters, where the base (parent) one has the global settings you want to apply - and you create child instances from it that adjust the template values.
See: https://support.pingidentity.com/s/document-item?bundleId=pingfederate-93&topicId=nxg1564002998160.html
Related
We're looking for 3 types of different access levels but don't know how to implement them using current identityserver4 features.
Have these scenarios:
We have an upper management system which some clients have access to specific pages or not, like admin or client(seems like Roles)
We have column type access level, for example, some users in the manager role can see a specific column/field or not, or in same roles shouldn't see some column/row data in reports.
We have a record level, access level, for example, some manager shouldn't see other branch client list. (like policies)
The whole process should be dynamic without any hardcode. and for doing these structures we should do some code on the back-end(middleware, etc) and some on frontend side(with a razor or etc).
any Idea how to implement these using identityserver4 authorization types?
The main feature of IdentityServer is to handle the authentication of the user and global authorization: which client has access to what resource.
Everything else could be considered out-of-scope of IdentityServer. Please read this article for some background information.
As an answer they've created the PolicyServer.
In the OSS version authorization has become a seperate (local) mechanism, while the paid version outsources authorization to a seperate server.
Extended with resource-based authorization you can implement authorization that covers all access levels.
I tried out with the ping identity documentation for the last days.
What are the factors of authentications that can be used as second factor in ping identity?
From where I will get a good example for two factor authentication using pingFederate?
Within the PingFederate Administration console you will need to configure IdP Adapters along with a composite adapter. A specific example would be to have the out-of-the-box HTML Form IdP Adapter and the PingID Adapter configured into a composite adapter. The composite adapter is essentially an authentication chain that utilizes individual IdP Adapters. In the example above, HTML Form Authentication would be the first factor that displays a username/password interface to the user. Assuming that is successful, the second factor in the chain would be PingID, which is a mobile phone app that the user would need to swipe to prove they have the phone associated to their username.
PingID is an integration kit that is available on the Ping Identity Download page https://www.pingidentity.com/en/products/downloads.html. If you download the PingID Integration Kit, the User Guide will show you how to configure two factor authentication.
Additional integration kits are available for Ping Federate that are listed on the downloads page as well. In addition to these download components, there are third party IdP Adapters available such as ThreatMetrix and RSA Adaptive Authentication for context-based authentication. From the perspective of the Admin Console, an IdP Adapter is an Authentication capability. Thus, multi-factor authentication is achieved through the composite adapter that chains together the IdP Adapters.
I have a question regarding the Attribute Contract configuration of an OpenToken Adapter for an IdP Server. As I was trying out the sample applications, it already has a config provided with it. Now that I'm trying to configure it without using data.zip, I'm having problems.
As I was trying to create a new adapter, the core contract subject shows up automatically. I have no idea what are the default attributes included in this contract.
Question: How will I edit what are the contents of this contract? Will my IdP Application handle it?
subject is the core contract, because that is what will carry the identity of the user, and is therefore the "minimum" - it must be returned (hence, "core"). Extended attributes can be added at the adapter, as long as the authentication method (such as a custom login page that retrieves attributes from a DB or something similar) can populate them into the token.
You may wish to review the documentation of the OpenToken Adapter.
Within PingFederate, the IdP Adapters are essentially Authentication plug-ins. There are many different types of IdP Adapters, whether it be the IWA IdP Adapter, HTML Form IdP Adapter, or the OpenToken IdP Adapter. The main use of the OpenToken adapter is to create a custom authentication plug-in that is an application you would implement. This is normally done for organizations that have very custom requirements for authentication that the out-of-the-box HTML Form Adapter or IWA Adapter cannot meet. The PingFederate sample applications for IdP show how to implement the interface.
When you use the OpenToken adapter, it is a secure interface between the PingFederate IdP Server and a custom application using the OpenToken specification. The custom application can be written in Java, .NET, or PHP and integrate using the OpenToken agent for the target programming language. As Andrew stated above, that custom application could query for attributes beyond simple authentication of the subject. Then within the application when the OpenToken is being generated you would need to insert the additional fields into the OpenToken. Then in the OpenToken Adapter hosted on the PingFederate you would need to configure the extended attributes using the matching syntax so that they could be used.
I'm using the out of the box Asp.Net Membership functionality to handle my user management and role management.
My application consists of a single database for each client and each database has its own Membership provider and role provider.
However, there are some users who work for more than one of the clients and I want to be use a single login and let them choose which client to view. I have everything setup to facilitate this "client switching" by using an intermediate database that stores all usernames and a relation to which clients they have access to. I also have it setup so any updates to a user in one database will update all of the corresponding users in the other databases. All of this logic is working very well, except that I can't seem to figure out how to tell ASP.Net to change to a specific MembershipProvider and use that one.
The process I thought I should use is as follows (when the user switches the client in the clients dropdown):
Log the current user out
Tell ASP.Net which Membership provider to use (selected based on the client chosen in the dropdown)
Log the current user in using the selected client's membership provider and refresh/redirect to the page they were viewing when they changed the dropdown
I know how to get a reference to the specific membership provider (Membership.Providers[MembershipProviderName]), but I can't find any information on how to tell ASP.Net to change its membership provider. I'm not really even sure how the asp.net Login control does this in the background either - something that would probably help me out in all of this.
I've been searching SO and the web for awhile and can't seem to find much about doing this other than a few threads where people are trying to modify the DefaultProvider attribute of the Providers element in their Web.config.
This MSDN tutorial may help you.
I’ve been asked to upgrade a few applications and I’m planning on merging all of them into one asp.net application. I’m fine with this decision and have spoken with fellow workers and they also think it’s the best option to go with.
The application will be accessed from a small group of users which belong to a larger domain. I’m currently planning on using Windows authentication and only allow this small set of users to access the asp.net application. Also there must be some role management, so that only certain users can view certain functionality.
I really don’t want to have many different windows groups; so I want to avoid having to assign different windows groups to different folders and control permissions in the web.config.
What I’d like to do is:
- Assign one windows group to the small group of users who will access the page.
- Create a custom membership provider and control the user who accesses the application. Depending on the user I will then assign his current set of roles.
- Add an application setting to the web.config, with the name of the current administrator, so if he logs in, he will be assigned all roles, and will be able to create and assign roles to other users.
I’d appreciate some advice if this would be the correct way to go about this.
Thanks!
I would check out the AccountManagement Namespace.
I like to use this. You can create a global security group (one for each 'role'). The account management namespace will allow you to fetch the UserPrincipal from AD with their logon name from the http context. Then you can check them for memebership in the security groups you created using the .IsMemberOf Method.