We run a Shibboleth Identity Provider, and have been increasingly asked to integrate with applications using non-Shibboleth SAML solutions, and encountering difficulty with regard to attribute naming. With a pure Shibboleth IdP & SP relationship, I know that the IdP can release user attributes to the Service Provider using arbitrary attribute names in the assertion. The Service Provider, having been configured to receive specific attributes using the IdP-provided names, re-maps the attributes from the IdP into attribute names useful to the Service Provider, using a configuration in the attribute-map.xml file.
My problem is with non-Shibboleth Service Provider operators, many of whom have refused to re-map attributes sent from the IdP, instead demanding new attributes be defined on the IdP (to carry values already available in existing attributes), using names dictated by the Service Provider owner. This causes the user's attribute object on the IdP to grow unnecessarily (at the time of authentication), because all defined attributes are populated with values first, and then they are filtered down to only those attributes approved for release to the requesting SP.
Is the attribute mapping feature, present in the Shibboleth Service Provider, part of the SAML/SAML 2.0 specification/standard, or is it a feature introduced by the Shibboleth developers? If it's part of the standard relationship/behavior in a SAML solution, can someone direct me to the authoritative standards document?
I've read through what I can find on OASIS regarding SAML standards, but I can't find anything regarding this behavior.
Attribute mapping is an application specific bit of functionality.
The SAML specification(s) details with things like message exchanges and XML schemas, not the functionality software should provide or how bi-lateral arrangements between IdPs and SPs should be organised. They have nothing to do with the SAML specification. Sorry.
Note that there are plenty of other SAML products that provide similar attribute mapping functionality, it's not just shibboleth that does so. I imagine the problem here is that the Service providers consider their requirements more important than yours and aren't prepared to make an exception. Either that or they don't know how.
Related
I work for a company that supports many applications, but for ease for users has an OAuth OIDC Single-Sign-On (IdentityServer4) so they can log in once and access many applications of ours. I have no problem configuring authorization to this OAuth with the returned JWT/Access Token.
But because our support footprint is so large, we have been told to handle roles, and user permissions at the application level. Here is where I am asking for feedback. I am currently developing a new API in .Net Core 6 (newbie to building APIs), and am wondering best practice for connecting a essentially third party OAuth, but also utilizing roles and permissions specific to the application.
The Identity Server returns a JWT/Access Token that is passed to API in form of bearer, but I need a mapping on the .net core backend to map the User contained in the JWT with a user within the application. Then the application can have separate mappings for roles/permissions, and utilize those roles as restrictions within the API, but I am not sure what best practice would be for this that also maintains the best security, while also achieving best performance. My thought was creating a middleware that creates and overrides userIdentity, but with that happening each call seems like unnecessary overhead. The other option is dual auth with cookie based auth that is set once, but am just unsure of best way, or what others have had success with. I know this must be a common flow that I am overthinking. Any insight is greatly appreciated.
It is common in many mature business systems to integrate identity and business data as you describe. There are two main techniques:
Identity system reaches out to business data at the time of token issuance, to get custom claims to include in access tokens. This Curity article explains the approach.
APIs look up custom claims, eg from a database, when an access token is first received, then cache custom claims for subsequent requests with the same access token. See this .NET code of mine for one way to do this.
In both cases the end result should be that the API business logic gets a useful ClaimsPrincipal that enables the correct authorization, as in this example class.
Finally, from an information disclosure viewpoint, aim to avoid returning detailed claims in JWTs to internet clients. It is common to use opaque access tokens instead, as a privacy preserving pattern.
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.
Migrating an SPA web app (Angular) and ASP Core Web API from Auth0 auth provider to Identity framework due to some requirements and limitations.
Until now everything was handled by auth0 and I didn't give it a much thought about the whole process of authentication. I would simply redirect users to auth0 hosted login page where it'd handle everything, callback with access token and I would use it for calls to API where API would just verify the JWT.
Now that I need to do this all manually, I am a bit confused. I want to have multiple authentication options: either Email/Password or OIDC auth providers like Google/Github.
I can get access token from these OIDC providers without much problem. But what do I do exactly with it, or to be more precise how do I configure Identity framework to handle the rest, without doing a lot of manual work? All users have quite a bit of additional data inside Identity framework user classes and I'm not fully sure how do i connect that to OIDC tokens.
Sorry for a bit abstract question, I think I'm missing some small detail, but at the moment I'm just really confused.
A lot of this is in place already, so to test the OIDC tokens, you just need them to be accepted by your consuming API.
To do so, you need to do some configuring, probably the same as you did for Auth0. Since the dependency here of the external providers, I'll post a link:
MSDN Google Auth
To accept them, you'll need the following steps:
register your API with the exteral provider
use the, provider dependent, instructions to set it up in your API.
The providers are additional to the one you have in placed and are referenced by Identity as ExternalProviders
In general, it's pretty easy. Possible some things are left out, since I don't know your exact use case.
So you are using an Identity Provider, previously Auth0, and now another (or custom) one.
Just for sanity a recap of your use case:
You trust the Identity Provider so every token signed by this provider is valid.
Your Identity Provider (and the external ones e.g; Facebook, Google etc) are responsible for their own user management.
Your own Identity Provider needs to handle specific authentication methods, tested against a corporate UserStore. These need to be managed, possibly with AD, Identity username/password or something similar.
Your Identity Provider provides authentication through JWTs
You also want to use external Identity Providers like Facebook etc.
So, as for the setup, you must do the following:
Implement (or reuse, or use ActiveDirectory or any other) user management tools, if you need to perform some management on them. This means password recovery and all that stuff, which is available in a lot of standard libraries (I think it comes out of the box in Identity)
Define clients, scopes and claims throughout your system(s). Possibly there is some effort to be made.
Make sure the JWT's are accepted as authentication throughout your system (this was already in place) and the proper claims are assigned when called for the correct client.
Register your API with the external providers
Setup your API to accept the external JWT tokens (needs some setup with secrets and API keys)
A lot of this is already in place in the Identity framework. There is an article about it here.
If you are willing to do a good exercise (and a lot of work), you could also try to implement things fully customized with IdentityServer4
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.
If a client accessing an endpoint implemented as an ASP.NET Web API Controller over HTTPS provides a client certificate, that certificate is available through Request.GetClientCertificate. However, I'm wondering: is it possible to get information provided in the form of claims-based model that was integrated with the security model in .NET 4.5?
The main reason I'd like to do this is that I need different clients to be able to authenticate in different ways to access the same services, so I'd prefer to abstract away from specifics such as certificates. I want my controller to be able to base its decisions on the claims for the current user without concerning itself about the provenance of those claims.
I know there's a X509CertificateClaimSet type, which makes it seem like the natural flow would be:
Client certificate passed via TLS/SSL gets represented as an X509CertificateClaimSet through some sort of token mapping process (similar to how the incoming cookie generated by the federated provider you can use for ACS gets handled by the SessionSecurityTokenHandler
A claims transformation module (something derived from ClaimsAuthenticationManager and configured with a <claimsAuthenticationManager> element) inspects the claim set that came from the certificate, and transforms that into non-token-specific application-specific claims
The handler looks for the application-specific claims.
There's even a X509SecurityTokenHandler, which sounds like it should do this. However, as far as I can tell, that's designed for scenarios where the certificate-based authentication is handled within the messages being sent - it doesn't appear to have any support for the scenario where the proof of ownership of the certificate happened at the transport level, i.e. as part of the TLS/SSL handshake.
I'm wondering whether I need to write my own module to do this. In theory, it looks like it might be a case of just handling the AuthenticateRequest event, looking in the request for the certificate, constructing a X509CertificateClaimSet from the certificate if it's present. But...then what? Do I just create my own ClaimsPrincipal and replace the existing user? Or is there some 'correct' way to add the claims I've discovered to the set? (A client certificate is not necessarily the only source of claims - my application is already using claims that come from integration with ACS. Is there a standard mechanism for ensuring that all possible sources of claims are correctly merged?)
It looks likethe SessionAuthenticationModule (SAM) is the identity model component that currently provides a claims principal, and it just replaces the one that was previously in the context and also the current thread's user. But it appears to provide extensibility - if you override its ValidateSessionToken, that returns the set of ClaimsIdentity objects that make up the principal. So in theory, I could override that and add any additional claims at that point.
But I'm not sure that's the way to go. As far as I can tell, the SAM does this after the ClaimsAuthenticationManager has done its claims transformation. Or is claims transformation the wrong model to go with here?
Have a look here: client cert auth and claims generation is part of Thinktecture.IndetityModel.
If I were you, I would externalize the authentication - let some other services provide the authentication and just return SAML tokens with required claims.
This way, in your application you don't really think of certificates, you just expect some concrete claims from federated identity providers.
Then, you implement one of your identity providers to actually accept certificates but the outgoing SAML hides this implementation detail and translates the certificate to a claim set useful to your application.