How to assign organizations when using SSO in API Portal 4.2

[StPaulPete]

Does anyone use single sign on with Portal 4+.  If so I'm wondering how you handle the assignment of users to organizations?

 

The intent of defining "organizations" seems simple enough, a way of restricting developer access to subsets of your API portfolio.  It makes no sense to us you can't apply the same logic to publishers, but that's beside the point for the purpose of this conversation.

 

When you configure SSO (we use LDAP), however, there seems to be no way to link a specific user's login to an organization.  If I understand, the "Organization" field of the attribute mapping in SSO can assign an LDAP attribute, but it is unclear how this relates to the user's specific session. 

 

For example, consider a scenario where I log in with "username1" and according to my group membership I am assigned a "developer" role, and the "o" attribute is assigned to the "Organization" field and has a value in the LDAP query result of "developerOrg1".

 

1.  I presume then, I must have defined an "organization" with the name of "developerOrg1" in order to match with this attribute?

2.  Is my "username1" user session therefore related to "developerOrg1", meaning I can access API's for that organization, and not for others?

 

Even if that's the way it's supposed to work, we have big problems with it because our LDAP returns no attribute that is workable.  "o" is simply our company name.  Everything we have is either too broad or too specific to be useful and our LDAP folks have no interest in adjusting attributes for this purpose.  Is there any way to relate a user id as returned by LDAP to an organization?

[Seiji Moriyama]

Hello,

 

I looked into the documentation of the API Portal 4.x but both user authentication and the "Organization" info are always served by the same Identity Provider unfortunately.
Probably the best way is setting appropriate values in one of available attributes in your LDAP for the API Portal 4.x.

 

Best regards,
Seiji

[StPaulPete]

Well, here are the results of my experiment.

 

We have an ldap group for developers.  We assigned it to the developer role.  We put a user in the developer group.  We set the CN in the organization field of Portal.

 

She was able to log in, and as far as I could tell she was able to do anything an admin can do.  In other words, it appears that LDAP SSO in general allows you to get in, but there is no way to restrict access within portal accordingly.  Everybody is essentially in the same role and there is no regard for organization arrangement, etc.  All that seemed to work when we experimented with local user registration, so it's looking like that's what we'll have to go back to.

 

Opinions?  Options?

[Zhijun He]

Dear Peter,

I thought it should be a matter of mapping roles, the document below could give you some ideas,

Configure Lightweight Directory Access Protocol - CA API Developer Portal - 4.2 - CA Technologies Documentation 

 

Regards,

Mark