How to configure Custom Attributes in SP metadata - single-sign-on

I came to know that in any SSO Solution if SP needs any additional attributes it can publish them in its metadata using AttributeConsumingService argument. The required attributes can now be added like as below:
<md:AttributeConsumingService index="0"
xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<md:ServiceName xml:lang="en">ABC</md:ServiceName>
<md:ServiceDescription xml:lang="en">ABC</md:ServiceDescription>
<md:RequestedAttribute isRequired="true"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oid:2.5.4.42"
FriendlyName="FirstName"/>
</md:AttributeConsumingService>
Now, if I want to add a custom attribute in my SP metadata, lets say "Role" of a user, how should I add it in the metadata? I mean, what would be its Name(this is what I'm unable to find!), NameFormat(is it urn:oasis:names:tc:SAML:2.0:attrname-format:uri?) and FriendlyName(can I give it as "Role" here?). I've not found anything related to this in the SAML2Core document.
Any suggestions please!
Thanks,
Abhilash

There is no universal answer as it depends on which IDP/federation you use and what is supported by it.
Generally, the friendly name is just a human-readable identifier for the attribute and the value can be freely defined.
The NameFormat and Name are defined based on Attribute Profile used by your IDP (e.g. Basic profile, X.500/LDAP Profile, ...). The expected values can be found in SAML 2.0 profiles document chapter 8.
You can find an example of how this is employed in practice for e.g. inCommon federation in their documentation.

Related

authlib: some client_kwargs in config are not used

Love authlib overall. Question about client_kwargs described in
https://docs.authlib.org/en/latest/client/frameworks.html
and https://docs.authlib.org/en/latest/client/django.html
Problem statement: I tried to pass "scope" and "audience" key/value pairs in the client_kwargs dict, but only "scope" key/value is used for generating URI for authorization.
I need to pass "audience" for Atlassian OAuth2.0 https://developer.atlassian.com/cloud/jira/platform/oauth-2-authorization-code-grants-3lo-for-apps/
Workaround found after some tinkering by passing "audience"="api.atlassian.com" to oauth.atlassian.authorize_redirect.
Question: Is client_kwargs in oauth.register/AUTHLIB_OAUTH_CLIENTS intended only for certain keyword arguments? If so, would be great to share it in the documentation; otherwise it would be convenient to set it in config together with everything else.
This behavior was found in 0.12.1 and 0.13.dev0.
Thanks!
Because OAuth 1.0 and OAuth 2.0 are different, this client_kwargs are designed to pass extra parameters to either OAuth1Client/OAuth1Session or OAuth2Client/OAuth2Session.
For your case, there is a authorize_params. You can put audience in your authorize_params:
oauth.register(
....
authorize_params={'audience': '...'},
....
)

Exposing verificationToken in built-in user model - Loopback 3

Subject says it all really. Just trying to figure out how to expose the verficationToken property of the default built-in user model in Loopback 3.
I've tried adding it to the "scope" definition in users.json, it works for other fields but not for verificationToken. I've also made sure to remove it from the "hidden" array in users.json.
I've read the very limited information provided on white-listing here (https://loopback.io/doc/en/lb3/Model-definition-JSON-file.html) and it talks about overwriting the toJSON method of the model, but I'm not seeing much info on how to do that, particularly for a built-in model.
Anybody every dealt with this before? Thanks in advance for any tips you might provide!
To access verification token,If you are using User.json by default it hides the password and verificationToken from accessing in rest api
By Default
"hidden": ["password", "verificationToken"],
change it to
"hidden": ["password"],

SharePoint REST: Field or property does not exist

I'm using REST to get data from a SharePoint library to display using the DataTables jQuery API. Everything is working fine, but I've got one stubborn field in this library that REST isn't able to grab.
The name of the field is "For", but the internal name is _x0046_or1 (not sure why, I didn't create the library). I've double-checked that this is the correct internal name using REST and by checking the code for my library view in Designer.
So using my REST call:
/_api/Web/Lists/GetByTitle('SAS2')/items?$select=_x0046_or1&$top=5000
And I get back:
The field or property '_x0046_or1' does not exist.
Anybody have any suggestions for a different way to reference this field that the REST api might recognize?
I did as Rohit suggested in the comments, and made the REST call without the select. It turns out that the actual internal name of the For field was "OData__x0046_or1". No idea why.
Thanks for the helpful suggestion, Rohit!
In SharePoint 2013 if you name a field with 3 or less chars and then end it with a number, SP will rename the internal name.

How to provide translations for field names with Symfony2/Doctrine2 via REST?

We have a backend built on FOSRestBundle (JMSSerializer) based on Symfony2/Doctrine2.
Our API e.g. delivers for some entity something like: 'valid_from': '2015-12-31' in a REST/JSON response.
Our AngularJS frontend consumes this REST API and e.g. presents some form to the user:
Valid from: 31.12.2015
Now I am wondering what's the best way to have a central/or maintainable place for a mapping like:
an English label for field key 'valid_from' is 'Valid from'
To my understanding all Translatable extensions for Doctrine (like Gedmo Kpn etc.) are to translate content (e.g. 'category' = 'Product' in English and = 'Produkt' in German) but not schema.
And of course I cannot change/adapt the field key to the language because it's the identifier for the frontend.
What I thought so far:
Use some mapping file between field_key, language_key and
translation on frontend.
Issue here is that the frontend needs to know a lot and ideally any change in the API can be done thoroughly by the backend developers.
Use some mapping file between field_key, language_key and
translation on frontend.
As we use annotations for our Entity model and JSMSerializer I'd need to open a totally new space for just translation information. Doesn't sound too convincing.
Create custom annotation with properties
Current idea is to use custom annotation (which would be cacheable and could be gathered and provided as one JSON e.g. to the frontend) with my entity properties.
That means any backend developer could immediately check for translation keys at least as soon as the API changes.
Something like:
#ORM\Column(name='product', type='string')
#FieldNameTranslation([
['lng'=> 'de-DE'],['text']=>'Product'],
['lng'=> 'en-En'],['text']=>'Produkt'])
A further idea could be just to provide some translation key like:
#FieldNameTranslation(key='FIELD_PRODUCT')
and use Symfony's translation component and have the content in translation yml files.
What is your opinion? Is there any 'best in class' approach for this?

Cannot use REST comments in Swagger

I have downloaded swagger ui and experimenting it locally. It works fine in scenarios like "path", "body" , and "query" . But most of my use cases use rest comments.
i.e /resourcePath/;tags
URI to retrieve the tags of a specific resource.
When I try this the the UI gets jumbled when adding the semi colon and malformed the sorted UI and cannot go beyond this.
So is this a known limitation ? Is there a workaround to accomplish this target ?
Appreciate any input to this..
Swagger is expecting you to specify path params in curly-brackets like {tags} and query params as comma-delimited, such as id=1,2,3,4. Some frameworks use semi-colons as delimiters but swagger likes commas.
Can you describe more what you're looking to do, with a more concrete example? Per design, comments on the api belong in the description and notes fields for operations, please see swagger-core wiki for details.
The Swagger codegen project has a validator which can be used to verify that your spec is properly formatted.