We are planning to use the Shibboleth technology to have a SSO login feature between multiple part of the software integration. I am still a beginner in this technology, but does anybody know if it supports user profiles? For example, if the user at a specific SP change his profile, another SP are also gets this info and automatically use the userinfo related to that profile.
Thank you for your help!
You can configure in attribute-filter.xml to limit/differentiate the values to SP(s).
Create a seprate AttributeFilterPolicy in attribute-filter.xml
Example : differentiate with regex and required attributes to SP
<afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterRegex" regex="^((?!(mysite.com)).)*" />
Assertion works like this : - IDP -> AttributeResolver(get the details
from DB/source by providing principle name -> Attribute filter -> SP
attribute mapper to get the information in Request Header.
Related
I have 2 Keycloak instances:
KC1 which is the main Keycloak for my app
KC2 which acts as an IDP (linked to KC1 via SAML protocol)
I'm trying to retrieve users info (email, name and roles, mainly) in KC1 whenever a SSO user (from KC2) connects to my app. As far as I understand this should be done via IDP mappers.
I tried creating multiple ones with the "Attribute Importer" type with no success. The main problem is that attribute name fields are just textboxes. I don't know where to look to get the correct value I should enter here. For instance for email I tried multiple things like "email", "emailAddress", "mail", etc.. (with all possible cases, i.e. all uppercase, all lowercase, camelcase, etc.) but this is just guess work.
Is there a table somewhere telling what we should enter here? Or at least some way to see what is being sent in the claims (everything is very auto-magic so it's hard to know what's going on under the hood).
The documentation ( https://www.keycloak.org/docs/latest/server_admin/index.html#_mappers ) mentions that you can put the log level to debug to see the claims. Couldn't see them personally, so not sure about that.
Edit : found the problem for basic info (I had to create client scopes with the correct protocol, in my case SAML, and then bind it in the client on the KC2 side. Then use the SAML attribute name defined in the client scope mapper).
However, I still struggle for the roles. Do I have to create them on the KC1 side as well?
Edit 2 : Solved. For future reference, the roles can be found in the access token (not the ID token like basic user info), but they have to be mapped in KC1 to be visible there.
However, I still struggle for the roles. Do I have to create them on
the KC1 side as well?
You can't simply import the roles from KC2 directly to KC1. Instead, you have to create the roles that you want in KC1, and in the appropriate IDP configuration section (of KC1) create a External Role to Role Mapper:
Where you map the role that the user has on the external IDP (i.e., KC2) to the one that the user should have in the KC1. Do that for every role that you want to map.
For SAML IdP integrations you can try the same idea but using the Advance Attribute to Role mapper:
I wanted to capture user attributes coming from SAP IDP(Identity & Authentication tenant service like department,salutation ,company etc ,via UserAccessor SDK api,but although those attributes are set and has value in IDP user and all the integration with IDP and sub account is in place post authentication ,user attributes object is empty ,i am only able to retrieve specific attributes like first names ,last name,email address ,user groups etc via JWT and UserAccessor api ,but no luck with other attributes ,in IDP i have mentioned these attributes as well under assertion attributes in SAP Identity authentication tenant .
Please guide and help in this matter .
Thanks Siddharth
Update: As we have now identified the problem, I will update my answer to reflect that. The original answer below is outdated:
Okay so the problem is that you haven't mapped any additional user attributes from your Identity Provider (IdP) to your JWT. As far as I'm aware there are three things you will need to do:
You need to create attributes in your xs-security.json (the file you used to configure your XSUAA service instance). This documentation should explain how to do that.
You need to configure which attributes are exposed by your IdP (in your case the SAP Identity & Authentication service. This documentation looks like a good place to start looking).
You need to map the attributes exposed by your IdP to the attributes defined in your xs-security.json. You will probably need to reconfigure (i.e. delete, recreate and rebind) your XSUAA service instance with the updated config, before you can do this step. Then, navigate to your application in the Cloud Platform Cockpit, from the left toolbar click "Security > Roles" and create your mapping.
Let me know if this works for you!
Original Answer:
As far as I'm aware the default IdP does not support SAML. Without SAML, I'm not sure whether you can propagate any attributes from your IdP into the JWT.
Please also check out this discussion for more information.
I am trying to find rest api which will tell me who is owner or admin of group using openAM restAPI.
Is this scenario valid by openAM? OR it does not support any such API .I am trying to dig documents of openAM till date but no luck yet.
Can anyone suggest if there is any API.
After going through docs in more details of openAM and looking at default openDJ schema i got to know there is attribute named owner. This attribute can be used for groups while creating them. But before i use this attribute i need to add to openAM through openAM console i.e configure the DATA Store in openAM and add the group attribute "owner". Now from my application through rest calls i set this "owner" attribute while creating group. SO i can see now who created the group information.
I have detail steps on this, if still anser is not clear let me know i can help here more.
Updated: Thanks for responding on my post. I am very sorry, as of today these were the requirement details. However, I can elaborate more on what I understand. I some idea on WIF, where I can write my own STS, RP and publish policies.
Couple of queries here. Do we need to have an IdP and should we connect STS to IdP. if not, can we go without IdP. I will have to use claim base authentication and federated identity mgmt in the application.we do not depend on AD/LDAP integration.
Imp Requirements are in this way. 1) we allow customers to do self registration who are direct users of this portal-M and the other set of users come from partner-X where the company claims are verified using SAML Req/Resp to access the portal-M. 2) once the direct user or user-thru-partner-X enters the portal-M, he/she should get access to another portal-N of partner-Y sending SAML request in similar fashion.
I have provided as much as details I know, since I am new to this technology of SSO/FIdM
I would happy to provide more information, if needed
Original
I have got a complex task to build a solution of externalized SSO with SAML that would be used by customers of different partners over web. the constraints are to build IdP/STS/Issuers/RP/Trusts/Policies with no open source or commercial product support choosing specific technology platforms such as Microsft or/and J2EE.
On top of these, IdP must have to use in house custom data store available on SQL Server and Oracle.
your ideas are appreciable and thanks in advance
So you want to implement a SAML stack without using any commercial or open source software?
That is a HUGE amount of work and you will need to spend a non-trivial amount of time getting your head around SAML.
In terms of a DB as your Identity repository, refer: Thinktecture IdentityServer.
In terms of SAML stacks, refer: SAML : A SAML stack .
A customer of ours has just purchased CQ5 and would like to externalize all of its security. We'd like to use an STS server for SSO and then leverage a custom authorization/attribute provider instead of the CQ5 repository. Ultimately, we do not want to use LDAP in any way.
Here is how we envision this (some pieces already working):
User browses to CQ5 Dispatcher running in Apache
Apache filter redirects user to STS site where login is completed.
User is redirected back to Apache with SAML Claims.
User ID token is placed as cookie into browser. (everything is working up to here)
CQ5 captures that cookie based on the SSO configuration (working)
Problem starts here: From here, we want to call a custom authorization provider for the user's attributes, roles, groups etc...
We have tried to figure out how to do this and can't seem to find the missing link.
Do we need to create a custom login module? Do we need to create a custom principal provider? Do we somehow use the existing LDAP capability in CQ5 but have it call a custom class which leverages the external auth source?
If anyone here has any idea how to do this, their karma quotient would be full for the year if they could share it. I'm not sure if this is a basic thing you do with JAAS or even where to put my classes after I've created them.
We've worked really hard on this so far and seem to be close, but we keep hitting dead-ends.
Thanks so much if you have an idea where to begin!!
-joe
Recent versions of AEM now include the SAMLAuthenticationHandler which allows you to:
Redirect users to SSO to simulate IDP initiated login, or
Allow AEM to perform SP initiated login with IDP
Specify attributes to take from the SAML Assertion and add to the user's profile node (not sure if you can use this for groups)
Specify which groups users should be added to
Set a cookie called request-path that will store the URL the user arrived at, and then redirect them to that location when they're authenticated (ie. deep linking)
This makes relying on the SAMLAuthenticationHandler better than using Apache to redirect. The current version of the handler bundled with AEM 6.2 does not properly set the cookie when using the redirect method, but Adobe does have an updated version that they can provide that will fix that problem.
I normally recommend that clients do not have their own authentication handlers developed inside AEM.
When not using LDAP, this does create an issue where users will not exist until they've logged in. Additionally, when your architecture includes more than one load balanced publisher, it is possible that a user may exist on one server user synchronization.
Try searching the google group for SSO details. Here's one useful post:
http://groups.google.com/group/day-communique/browse_thread/thread/72c235c83a501252/fba4d08a90487156?lnk=gst&q=SSO#fba4d08a90487156
It seems that you will have to implement a custom LoginModule, more information here: http://dev.day.com/docs/en/crx/current/deploying/custom-login-modules.html