I'm trying to use a SAML relying party and send a custom UI content definition parameter, as disccribed in the docs. https://learn.microsoft.com/en-us/azure/active-directory-b2c/customize-ui-with-html?pivots=b2c-custom-policy
Example:
<RelyingParty>
<DefaultUserJourney ReferenceId="SignUpOrSignIn" />
<UserJourneyBehaviors>
<ContentDefinitionParameters>
<Parameter Name="campaignId">{OAUTH-KV:campaignId}</Parameter>
</ContentDefinitionParameters>
</UserJourneyBehaviors>
...
</RelyingParty>
OAUTH-KV doesnt work with SAML (obvisously).
Is there any other way of getting a parameter sent with SAML that I can use as a ContentDefinitionParameter?
FYI we are already using {SAML:ProviderName}, {SAML:Issuer} and {SAML:Subject} for other purposes.
The only supported values will the the claim resolvers listed in the documentation for SAML: https://learn.microsoft.com/en-us/azure/active-directory-b2c/claim-resolver-overview#saml
The best candidate for passing arbitrary data in the query string is {SAML:RelayState}.
The main reason for the difference is that OAuth explicitly allows for arbitrary parameters in the request whereas SAML is much more strict.
Related
I´m using OpenAM as hosted SP and need to evaluate the value of one attribute in the remote IdP assertion in order to replicate the same behavior seen in LDAP authentication chain, when user filter is set to ("SpecialAttribute"="TRUE"). The attribute is available in the assertion, and I added it in SP/Assertion Processing/Attribute Mapper ,
Now I don´t know what to do. Is this, at least, the right direction ?
Any help is very welcome!
From your description I suspect you want to achieve that when the SAML response includes the attribute SpecialAttribute with value TRUE, the SAML SSO flow should be successfull and when the value is different or when the attribute is missing, the SAML SSO flow should fail.
Given this suspicion, you need to create an SAML2 Service Provider Adapter implementation and check the SAML response in the preSingleSignOnProcess method. If the attribute does not meet the criteria, throw a proper SAML2Exception
I am using IdentityServer4 via ASPNET Core, and I want users to access my API both by the web browser via their identity (Implicit and Hybrid), and by clients programatically (Client Credentials). I realize all I have to do is add AddIdentityServerAuthentication and I am done. However, that only solves the authentication aspect of this problem, not the authorization.
Authorization:
With ASPNET Core, you can just use Role based auth (or PolicyServer permissions which is similar) but only if you have an identity with role claims, that does not work for client credentials. So that brings us to needing to secure by role, or policies AND by scopes. How can I do this?
You cant have multiple policies, if you do, they both must pass.
You can't have multiple auth schemes, because my call to AddIdentityServerAuthentication will have to use the same authority, so how would IdentityServer4.AccessTokenValidation/JwtBearer know which you scheme challenge you are trying to pass?
Multiple requirements could work, but you need to add extra requirements on the condition that you are dealing with a non-identity access token. How can you detect what type of token you are dealing with? Is it safe to just say "If no sub, this is client creds."
Should I scrap this design and force device code flow on my users? Look at az cli it magically opens a browser, and then you can start scripting away to your hearts content. IS4 supports this with ease, especially with verficationUrlComplete
I think I have a working POC, but I am far from happy with it. https://gist.github.com/VictorioBerra/8c333a228c55d86a7c15f7f300284634
It involves basically re-implementing the default scope claim requirement handler and policyservers permission requirement handler. But thats the only way to conditionally apply the requirement handlers based on the token type.
There are at least a couple of ways of how to go around your problem of implementing role based authentication:
You might have misunderstood the fact that a client can have role claims in the client_credentials flow.
You could even have sub claim if you implemented client_credentials_custom flow and essentially bind a client to a particular user account (think of this as a service account)
Currently we're generating Swagger 2.0 documentation using Swashbuckle.AspNetCore. The authentication mechanism being used requires three headers:
X-API-KEY: The shared key
X-API-SIGN: Signature of the request composed of HMACSHA256 hashed value of Hashed secret, Timestamp, Method, Endpoint, and Body
X-API-TIMESTAMP: This is the same timestamp used in the signature
I don't think Swagger or Swashbuckle support this natively so I would likely need to set up some javascript to fill in hidden fields or something in the swagger docs.
I'm currently using an OperationFilter to prepend operation parameters to each request. This doesn't help me once the page loads though since the user will need to enter their API key and secret, which everything else is calculated based on. Clearly javascript will be required here.
Can anyone provide suggestions for how to handle this cleanly?
I wanted to put this as a comment but comments do not allow format so here you go:
The Swashbuckle.AspNetCore seems to be missing the InjectJavaScript feature:
https://github.com/domaindrivendev/Swashbuckle.AspNetCore/search?l=C%23&q=InjectJavaScript
It is there on the older project:
https://github.com/domaindrivendev/Swashbuckle/search?l=C%23&q=InjectJavaScript
That is what I've used to inject some javascript, without that we are very limited.
Now looking at this from a different perspective:
It seems you want to embed the authentication process on the swagger ui...
Maybe on the backend you should bypass the authentication if the request comes from Swagger-Ui
I want to create a custom API that behind the scenes, call number of other APIs which use OAuth 2.0 for authentication. I want to manage this internally so that my custom endpoint somewhat abstract this.
Or to begin with I want to do what app like buffer (https://buffer.com) do - where you connect to different social services and than post your status.
How can I achieve this in .NetCore ?? I don't want to login with these (a lot of samples are catering this scenario), user login is different than this. I just want to establish these connections (like API Connections if you look at Azure API Management) and then perform some operations against those endpoints.
I hope i convey my point. please let me know if this isn't clear.
Thanks
Sanjay
OAuth2 systems are all based on the same workflow.
here's an authorization url, you pass some ids in an authorization header, if everything is correct you get a token, you then use the token to do whatever you are allowed to do. What changes are the credentials you use for authentication and the urls you hit for the various parts of this workflow.
You could write your own OAuth2 library which deals with all this, that's pretty much what I did and simply changed the details for every specific system I had to interact with.
This being said you can always use one of the existing implementations to connect to the various systems you care about, they all have an API you could use, all you have to do is make sure you follow the OAuth2 flow correctly.
Why use the proposed OpenID OAuth Extension over another OAuth-based protocol?
Discovery doesn't seem to be a feature. Although the consumer only needs a claimed identifier to start the authentication process, any authorization will still require that the consumer knows the access token URL, signature methods, and have a shared key/secret with the provider.
One benefit is that there's a specified way to ask for specific authorizations, the openid.oauth.scope argument to the authentication request. And one specific benefit for this is that authentication only - for the benefit of the consumer only, with no verifiable token - is defined for free and can be performed without worrying about keeping track of outstanding tokens or the resources they might require.
Are there examples of alternative ways in use to specify the scopes to be requested, perhaps with something in OpenID discovery? Or could this be handled effectively with some kind of REST navigation before the OAuth process, where one of several request token URLs specific to the desired scopes is discovered by interpreting hypertext starting from a well-known URL?
I am researching a delegated authentication and authorization system with several authorization scopes, where the scopes are relevant for different interactions. In other words, the consumer needs to tell the provider which scopes should be presented to the user for authorization.
The OpenID+OAuth extension really has only one significant advantage over standard OAuth:
If you need to authenticate the user and access the user's private data, and the OpenID Provider happens to also be the OAuth Service Provider (the user authenticates with the same service that holds his private data), then the extension will help the user have just one redirect to the OP+SP instead of two separate ones. For the user, this is a huge usability win -- if he happens to be authenticating with his SP.
The risks of supporting the extension is adequately supporting users whose OP and SP are not the same entity (you don't want to say you'll support the extension and then inadvertently lock out users whose OP is not also their SP).
Keep in mind what you really need to know. If you only want to access the user's private data, but don't really care who the user is that you're interacting with, use just OAuth. No reason for the user to give up his identity via OpenID if you're only downloading his photos to offer a photo printing service, for example, or if you already have a non-OpenID account for this user.